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ABSTRACT 


The multi-backended database system (MBDS) is a database system designed 
for very large peraaeed MBDS is intended to provide consistent performance 
with increased capacity (or improved performance at a sustained capacity) by dis- 
tributing the work of the system among several micro-computers connected to a 
common communication network. One of the issues central to the MBDS design 
is the portability of the system’s software. This thesis provides a general discus- 
sion of the issues involved in software portability, and then presents a case study 


of the MBDS software system. 
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lL AN INTRODUCTION 


A. THE BACKGROUND 

It should come as no surprise to anyone involved in computer science to say 
that the essence of the entire field is changing. This is probably true for those 
persons involved in software development. The trend of rapidly decreasing 
hardware costs remains steady. and ahoe no signs of changing course in the near 
future. Software costs therefore represent an ever increasing percentage of total 
system costs. 

As the level of technology increases, and the relative costs of hardware con- 
tinues to decrease. the expense of upgrading to larger. more powerful computing 
systems becomes less restrictive. Except for the ever present (and increasing) cost 
of new software, the obvious requirement then is for the software to be easily 
ported from one system to another. Assuming an environment of truly portable 
software. users would find themselves in a situation where the only real costs to be 
considered when evaluating a change to a new system would be the cost of the 
hardware alone. 

There are some obvious benefits to this situation. When the need arises for a 
greater capacity or an increased throughput to meet the new requirements. the 
upgrade becomes an easier task. Additionally. more powerful software can be 
purchased at the outset. when the original computing systems are acquired. Since 
the useful life of a software item would no longer end when its underlying 


hardware is replaced, higher initial expenses for software could be justified. 


Cost is not the only factor in support of software portability. It is often desir- 
able to provide a uniform. consistent environment across several different comput- 
ing systems. The davs of the single mainframe which supports all of the com- 
puter needs in an organization are fading. Many organizations now have several 
different computing systems (usually minis or micros). They may be made by 
different manufacturers, run by different operating systems. used for different 
tasks, and are networked together frequently to provide a very powerful comput- 
ing environment where resources may be shared. 

It is also common to see that the same operating system is running on several 
different computers (e.g., UNIX, which runs on VAX main frames, ISI 32-bit 
micro-computers, IBM 16-bit micro-computers, et. al.). Conversely, hardware 
manufacturers often provide a choice of operating systems which will run on the 
same hardware: and applications developers will provide versions of their software 
which run under different operating systems, and allow exchange of data between 
them without modification. In such an environment it is not unreasonable for a 


user to desire programs which can be moved between several computing systems. 


B. AN OVERVIEW 

Portability is essentially the abilitv of software to migrate among different 
hardware configurations and operating systems with little, or no. modification. 
This thesis will provide a discussion of techniques which can be used to achieve a 
higher degree of portability for software in general. and database management 
software in particular. 

The need for portable software is evident through all areas of computer sci- 
ence. database management systems (DBMS) present a particularly strong need 


for it. Conceptually. DBMS software can be thought of as a specialized operating 


system. Like an operating system. DBMS accepts commands from a command 
language (data language). and uses the commands to manage and manipulate files 
(data). System users utilize both DBMS and the operating system as support 
tools. Like operating systems, the DBMS software tends to be complex and 
expensive. often taking many years to develop. 

The DBMS software however presents something of a paradox in that the 
more powerful DBMS is, the quicker it exceeds its usefulness. This happens not 
because DBMS ceases to be adequate, but because the hardware on which the sys- 
tem is running can no longer handle all of the work which the DBMS software is 
trying to accomplish. 

The better DBMS is. the more users there are. Unfortunately. the increasing 
strain which a growing database places on a computing system is not linear. 
Response times increase drastically, and soon. running nondatabase operations 
concurrently with DBMS becomes infeasible. Eventually. even running DBMS as 
a standalone system becomes uneconomical. 

One obvious answer to this dilemma is to go to larger. stand alone. comput- 
ing systems for handling database functions. There is no reason to believe. how- 
ever, that this is anvthing but a short-term solution. Databases will almost always 
continue to grow. so the emphasis is once again on the need for the portable 
DBMS software which can be moved from one system to another system. 

Researchers in the area of database management are finding new ways to 
improve the efficiency of the DBMS software, and reduce the strain that the — 
DBMS software imposes upon the mainframes called hosts. One current project. 
is the multi-backended database system (MBDS). MBDS is aiming at meeting 
both of these goals by placing the DBMS software on independent micro- 


computers known as the backends which are connected to each other, and to their 
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host via a communications link. Since most processing with MBDS is on indepen- 
dent computers. no real strain is placed upon the host computer. MBDS provides 
for increased capacity without decreased performance (or increased performance 
at the same capacity), by the addition of micro-computers. 

MBDS places no restraint on either the host computer type. or the micro- 
computer backend. There is also no restriction on the method used to establish 
the communications link. In order to provide this freedom, and since the system 
is designed with the intention of migrating to various hardware configurations 
(possibly at frequent intervals), the MBDS software must be easily portable. 

Due to the great desire for portability in database software and the addi- 
tional efforts by the designers of MBDS to achieve it, MBDS represents an excel- 
lent example of methods which can be used to provide software portability. The 
methods used are applicable to the software portability in general, and to the por- 
tability of the DBMS software in particular. As such, one implementation of the 
MBDS design is used for discussion throughout this thesis. A complete descrip- 


tion of MBDS design can be found in Reference 1 and Reference 2. 


C. THE ORGANIZATION OF THESIS 

Chapter I] presents a paradigm for a software system. and describes the parts 
of a computing environment. A discussion is presented on how the various com- 
ponents of a software system (presented in the paradigm) interact with each part 
of the computing environment. Also discussed are the effects that changing each 
part of the computing environment have on the components of a software system. 

In chapter III we describe the components of the multi-backended database 
system (MBDS) according to the framework of our paradigm. The porting of 


MBDS from one computing system to another is discussed, and the effects of the 
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porting on the MBDS software components are presented. The actual 
modifications which are necessary to port the MBDS software are presented in 


chapter IV. 


re 


Il. THE SOFTWARE-SYSTEM PORTABILITY 


Before progressing with any discussion of how to achieve the portability of a 
software system we must have some concept of what portability is, and what 
comprises a software system. Only then can we correctly determine what the 
issues are and their impact upon the portability. and how these issues should be 
approached and analyzed. Probably no two definitions of the software portability 
exactly coincide. depending on the background of the person providing the 
definition, and the scope of the problem at hand. However, there are some gen- 
eral points that all of the different definitions are likely to agree on. 

The software-system portability is the ability of a software system to migrate 
from one to another computing environment (i.e., hardware and operating system 
combinations) with little, or no, changes of the software system required. Changes 
which are required should be consistent and of a regular nature. so that these 
changes can be accommodated, if possible. by some mechanical means. 

Given this definition, we now must focus on what constitutes a software sys- 
tem. Software systems can be designed for many different purposes. In order to 
carry out their intended job they usually have various parts (some times hundreds 
of them), each of which satisfies some specific requirement. There are usually sec- 
tions for carrying out normal processing and for creating and manipulating data 
structures. Most software systems also require access to device drivers to enable 
terminal I/O or communication with other software systems, either within the 


same computer or over some distributed network. 
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Regardless of the software system in question. its portability is not deter- 
mined by what the software system is intended to do. or how many parts it has. 
but by how the software system was structured. Therefore. the issues affecting 
the portability are general to all types of software systems, since all of the 
software systems have some structure. The concepts to be discussed do not vary. 
nor does its basis. on whether the software system is a database system. operating 
system, a compiler. or any other type of systems. In the rest of this chapter we 
examine what those issues are. A case study on the portability is presented in the 


next chapter, using the multi-backended database system (MBDS) as an example. 


A. A PARADIGM FOR A SOFTWARE SYSTEM 

In this section we present a paradigm for the structure and form of a software 
system. This paradigm is based on the two types of components that are used to 
construct a software system. They are system source code and operating system 


commands. There are three types of system source code, namely, 


e machine code. 
e assembler code. and 


e high-level code. 
Operating system commands take the form of 


e basic commands. 
e command files. and 


e utilities. 
First. we investigate the system-source-code component. For each type of 
code in the system-source-code component. our paradigm provides up to three 


types of processing: 
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e basic processing. 
e runtime-environment processing. and 


e translator-environment processing. 


In the following discussion, we investigate the form that each of the three kinds of 
processing takes for each of the three types of the system source code. 

The machine code is just binary code written for the particular machine the 
program runs on. The basic processing functions for machine code include opera- 
tions such as add, subtract and store. There is no runtime-environment process- 
ing, or translator-environment processing available with the machine code. 

The assembler code. while it is at a higher level than the machine code. usu- 
ally results in only a few machine instructions per line of the source code. The 
capabilities at the basic processing level for the assembler code parallel those of 
the machine code. However. the assembler code allows logical names and per- 
forms the automatic calculation of machine addresses. The runtime-environment 
processing for the assembler code involves calls to the operating system for per- 
forming such functions as reading characters from files, or obtaining the current 
date and time. Assemblers generally do not provide any translator-environment 
processing capabilities. 

The high-level code refers to compiler languages such as C or Pascal. For the 
high-level code, basic processing capabilities include mathematical operations, log- 
ical comparisons. and assignment of values to logical variables. They also include 
all those statemelits in the language which we call the runtime-environment pro- 
cessing or translator-environment processing. The runtime-environment- 
processing capabilities include operations such as reading and writing files. 
dynamically allocating the memory and providing calls for communicating with 


other software systems. The high-level calls to be carried out by the operating 
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system. constitute the sruntime-environment processing. The _ translator- 
environment processing is any function that is carried out by library routines 
which are provided as a part of the translator and incorporated into the software 
system at the link time. Included in the translator-environment processing are 
operations such as floating-point arithmetic, computation of trigonometric values 
and manipulation of character strings. 

Now let us consider the operating-system-command component of a software 
system. The basic operating system commands include those for compiling, 
assembling and linking the source code of all types {i.e., machine, assembler and 
high-level); and for deleting. copying and renaming files. Command files are lists 
of basic processing commands which automatically execute. in sequence, or 
according to some programming logic dictated by the operating system. The util- 
ities of the operating system are prewritten command files which are included as a 
part of the operating system. Utilities may perform logically complex operations 
and are designed to aid in the implementation and management of large software 
systems. Included in these are system libraries and implementation aids such as 
version control systems and file-creation utilities. 

We should take the time here to note an important point. While all of the 
code is eventually translated into the machine code and runtime libraries may 
make calls to the operating system. neither of these directly affects the portability 
of the software. The issues are what types of the system source code that the 
software system is written in. and which types of processing are performed. These 


are what determine the portability of the software system. 
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B. P¥PES OF POR Tete 
We have defined the porting as the movement of a software system form one 
computing environment to another. There are three parts which make up a com- 


puting environment, 


e the hardware. 
e the operating system, and 
e the translator (in the case of the assembled or high-level code). 


A software system may be ported by changing any of the three parts of the com- 
puting environment. Each of these changes has a different impact on the software 
system being ported. There may of course be changes to several items at once. 
For example, a change of operating systems usually requires a change of transla- 
tors as well, since most compilers are written to run on a particular operating sys- 
tem. We now use the paradigm we have created to examine the effects that each 
type of porting has on a software system. 
1. <A Change of the Hardware 

For any software system. the most profound effects of changing hardware 
are in the system-source-code component. Any portions of a program written in 
the machine code obviously are affected by a change of the hardware. Unless the 
new hardware used allows for the emulation of the original machine, all machine 
code must be rewritten. The assembler code usually must be redone as well 
because it 1s so closely tied to the structure of the underlying machine. 

The high-level code usually does not have to be redone due solely to a 
change of hardware as long as that new hardware supports a compatible version 
of the original operating system and that a compiler is available for the high-level 


language in question. However, this is not always the case. If the high-level 
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language is not widely used (e.g.. BLISS). then there might not be a compiler 
available with a code generator for the new machine. 

Operating-system commands are not affected by a change of the 
hardware alone. since two versions of an operating system running on two 
different sets of hardware can usually be expected to provide the same functions. 
Thus, in the case of a hardware-only change, the type of code used (machine. 
assembler, or high-level) is what determines the changes to be made to the system 
source code. There is usually no affect on the operating-system-command com- 
ponent of the software system. 

2. A Change of Translators 

Changing the translator only has an effect on the assembled and high- 
level code in the system-source-code component (the machine code does not use a 
translator). The kinds of processing which the code (assembled or high-level) per- 
forms affect the changes which have to be made. Necessary changes to the code 
which accomplishes the basic processing are determined by the degree of the 
language’s standardization. 

In addition to intentional design differences there is a question of 
whether a particular translator correctly implements the intended language. For- 
mally validating compilers for modern high-level languages is not possible. Most 
commercial compilers are subjected only to some series of empirical tests. If 
minor differences from the defined language are detected. manufacturers may 
decide to document the deviations, rather than pay the expense of trying to 
correct them. These deviations may affect how well a software system reacts to a 
new compiler. 

Even if the syntax of a language is standardized, changes may be 


required in portions of the code which do the translator-environment processing. 
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The runtime libraries provided by the compiler suppliers are not always the same. 
A good example of this is Pascal's string manipulation routines. While the 
language itself does not define string types. almost all implementors include them 
aS an extension to the language. However. the format used by each is not stand- 
ardized and often differs among compilers. While the old and new translators may 
both provide functions that have the same name and take the same parameters, 
there may be logical differences in how each of them implements these functions. 
If these functions perform critical operations in the software system, it may be 
desirable to avoid the runtime-environment processing whenever possible and 
write your own routines instead. 

For the system-source-code component of a software system, the changes 
necessitated by a change of translators is determined by the type of processing 
done by the code. There is usually no effect on the operating-svstem-command 
component of the software system. 

3. A Change of Operating Systems 

It is the operating system which provides the major functionality in a 
computing environment. A change of the operating system therefore is the most 
drastic kind of porting. Porting software to a new operating system may affect 
the assembler-code and high-level-code portions of the system-source-code com- 
ponent. The machine code (which relies only on the underlying machine) does 
not have to change. The most direct effects of changing operating systems are to 
those code sections which do the runtime-environment processing. If the new 
Operating system does not provide equivalent functions for those operations. it 
may become necessary to redesign the logic of entire sections of the code. 

The portability of a software system may also be complicated by the fact 


that a change of operating systems requires some changes to the translator which 
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the software system has used. This subjects the software system to all of the pos- 
sible changes it would have to undergo for any other change of translators. 
Therefore. changing operating systems has an indirect effect on the code which 
does the translator-environment processing and, possibly, the basic processing as 
well. 

Changing operating systems obviously affects all parts of the operating- 
system-command component of a software system. Basic commands (e.g., com- 
pile, link, search, etc.) are almost always supported in some form by the new 
operating system: command files usually are available as well. Therefore, the 
changes required by these commands are a matter of substituting the new formats 
for the old. The greatest difficulties arise if operating-system utilities have been 
utilized and the equivalent utilities do not exist in all operating systems. When 
they do exist. their formats may not be at all similar. In either case, an extensive 
restructuring may be necessary to maintain the software. 

The porting to a new operating system may require major changes to 
both components of a software system. In the system-source-code component. the 
assembler and high-level code may have to be changed. These changes may affect 
the code which does any of the three types of processing. For the operating- 
system-command component, a major rewriting is usually necessary for all three 


forms of operating-svstem commands. 
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WI. THE IMPACT OF THE MBDS DESIGN ON PORTABILITS 


In this chapter we present a case study of the porting of a particular software 
system from one computing environment to another computing environment. 
Our description of the software system that was ported follows the structure of 
the paradigm presented in the previous chapter. The description of the actual 
porting also follows the format we presented in the previous chapter (i.e.. describ- 
ing each part of the computing environment which changed and how the change 
affected each component of the software system that was ported). 

The software system that was ported for our case study is the multi- 
backended database system (MBDS). MBDS is a database system (for very large 
databases) that was developed for research purposes at the U. S. Naval Postgra- 
duate School. The basic premise of MBDS is to distribute the work of the data- 
base system across several different micro-computers. MBDS uses one computer 
as the system controller. and several other computers (at present, eight) as back- 
ends to accomplish the majority of the required database-manipulations. There 
are two reasons why MBDS was chosen for our case study: 1) MBDS has been 
ported successfully twice since its initial implementation. and 2) the MBDS 
designers have established portability as a high priority since the initial inception 
of the MBDS project. Including the first implementation. MBDS has been run in 
three different computing-environments. Among the three computing- 
environments, there have been four different hardware configurations (MBDS uses 


more than one computer per environment), and five different operating systems. 
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To attain a portable software system. the designers of MBDS strived to 
develop the MBDS software so that it contained a high degree of hardware and 
operating-system independence. By engineering MBDS with a minimum amount 
of dependencies, they greatly enhance the probability that the software system 
would be easily transportable to new, and varying, hardware/operating-system 
configurations. 

To develop a highly portable database system. the designers of MBDS first 
identified which portions of the database system software are dependent on either 
the hardware and/or the operating system. They identified two classes of data- 
base system software which are dependent, namely. communications software and 
disk input/output software. Communications software is used by the database 
system to communicate among different computers and to communicate within a 
computer, referred to as inter-computer and intra-computer communications. 
respectively. The communications software is often affected by a change of the 
operating system (since communications protocols are operating-svstem depen- 
dent) and is also affected by a change of the hardware (since specialized commun- 
ications drivers are hardware dependent). The disk input/output software is used 
by the database system to access and process information from the secondary 
storage. The disk input/output software is also affected by a change of the 
operating system (since it is operating-system dependent) or by a change of the 
hardware (since it is dependent on specialized disk drivers). 

In general, there is no way to avoid a certain amount of hardware and 
operating-system dependencies in a database system. Instead, MBDS was 
developed with techniques which can minimize the effect of changes. There are 
two distinct approaches to accomplishing this task. First. MBDS uses the con- 


cepts of abstraction and encapsulation to isolate the dependencies of the 
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communications and disk input/output software. The database system software 
makes calls to these high-level routines that are dependent on the programming 
language used in the software system, when there is a need to access the system- 
dependent software. These calls are generic. e.g., send|message. destination], 
receive[message, sender], do disk io[data, device]. They represent abstractions of 
the actual functions. The routines themselves (i.e., send. receive. and do disk io) 
are used to encapsulate the system-dependent software. Second, the designers 
used the concept of a virtual interface to develop independent software for com- 
munications and disk input/output. The aim of the virtual interface is to utilize 
abstractions provided by the compiler to accomplish a particular task. These 
abstractions are usually in the form of library routines for the programming 
language. As these library routines are supported by different compilers under 
different operating systems, it is easy to transport the virtual interface from one 
Operating system to another. 

MBDS has utilized the abstraction and encapsulation concepts. as well as the 
creation of a virtual interface. Abstractions and encapsulations are used by the 
MBDS communications software to provide high-level calls to send and receive 
messages both among and within computers. Since MBDS is a message-oriented 
system, all of the inter-computer and the intra-computer communications are 
accommodated by the abstractions and encapsulations. These techniques are also 
used by the MBDS disk input/output software to provide a high-level interface 
for reading (writing) information from (to) the secondary storage. In sao 
the MBDS designers also created a virtual interface for disk input/output 
software. The virtual interface depends on the programming language constructs, 
and is used to provide a high-level, operating-system-independent paradigm for 


performing disk input/output via text files. 


22 


In the next section we take a closer look at the construction of MBDS accord- 
ing to our paradigm of a software system. An in-depth description of the MBDS 
_ design can be found in Reference 1 and Reference 2, descriptions of the implemen- 


tation of MBDS can be found in Reference 3 and Reference 4. 


A. THE MBDS COMPONENTS 

The system-software component of MBDS contains only high-level code 
(there are no sections of machine code or assembler code). This has greatly 
enhanced the portability of the MBDS software system. The MBDS high-level 
code (written in the C programming language) performs all three types of process- 
ing contained in our paradigm (i.e., basic, runtime-environment and translator- 
environment processing). 

The basic-processing operations of MBDS are the normal C language con- 
structs which would be found in any C program (e.g., for-loops. while-loops. if- 
then-else statments, etc.). These basic-processing operations carry out the major- 
ity of the processing in the MBDS software. We have stated in the previous 
chapter that portions of the system-source-code component which are written in 
high-level code and perform basic-processing operations are inherently portable. 
Therefore. the majority of the MBDS software svstem is inherently portable. The 
portions of MBDS which do runtime-environment-processing are those sections of 
high-level code which perform inter-computer communications. intra-computer 
communications. disk input/output and system-timer operations. 

Translator-environment-processing operations in MBDS are performed by 
function libraries provided with the C compiler. They consist essentially of rou- 
tines for performing terminal input/output and routines for the extensive 


character-string manipulations which the MBDS software performs. MBDS also 
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performs some disk input/output at this level. when dealing with files used for 
execution-trace information and user input. All of the manipulation of the 
database-files is done at the runtime-environment processing level. under the guise 
of abstraction, encapsulation and virtual interface techniques. 

The system-software component of MBDS consists of over eighteen-thousand 
lines of C code. In order to implement and manage such a large software system 
the designers of MBDS make extensive use of the operating-system-command 
component of MBDS. Operating system command-files are used to gather the 
required system-source-code files in one place, compile and link them into execut- 
able files, relocate all executable files in Aiieuaree for later execution. and then 
erase any intermediate (temporary) files which are no longer needed. In addition, 
since the MBDS software system consists of multiple processes running across 
several computers (usually five processes per computer). command files are util- 


ized to initially start the system in an orderly fashion. 


B. PORTING THE MULTI-BACKENDED DATABASE SYSTEM 

This section discusses the actual changes made to the MBDS computing- 
environment each time MBDS was ported. and the effects that each of those 
changes had on the MBDS software. Each time MBDS was ported. changes were 
made to both the hardware and the operating system at the same time (the com- 
piler also changed, because of the new operating system). For the sake of clarity. 
each of these changes is discussed independently. 

1. Changing the MBDS Hardware 

MBDS has had three different hardware configurations. the first 

configuration is the original. The controller for MBDS is a Digital Equipment 


Corporation (DEC) VAX-11/780. The backends are two DEC PDP-11/44s. For 
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the database store. each backend utilizes a 67-megabvte RM03 disk drive. Inter- 
computer communications 1s accomplished using the point-to-point parallel com- 
munications link (PCL). a 0.5-megabit bus. Three PCL’s are utilized. one from 
the controller to the first backend, one from the controller to the second backend 
and one between the two backends. 

In the second configuration the controller for MBDS is a DEC VAX- 
11/750, the backends for MBDS are eight Integrated Solutions Incorporated (ISI) 
Motorola 68020-based workstations. For the database store, each backend utilizes 
a 500-megabyte Control Data Corporation (CDC) winchester-type disk drive. 
Communications is accomplished using an Ethernet. All computers (both con- 
troller and backends) share the same Ethernet. 

For the third configuration, the controller for MBDS once again is a 
DEC VAX-11/780, while the backends are upgraded to DEC MicroVax-IIs The 
communications bus is also upgraded to a DELNI. with DECNET providing the 
networking software interface. Each backend has a 71-megabyte DEC 
winchester-type disk drive. 

Since all of the MBDS software system consists of either high-level 
system-source-code or operating-svstem-commands. we can expect that no 
changes would be required to the software solely because of a change of the under- 
lying hardware. That is in fact what happened. In both cases. where MBDS was 
moved from one piece of computing hardware to another. no changes had to be 
made to the MBDS system-source-code (as ‘ result of the hardware). There were 
also no changes required the operating-system-command component of MBDS. 

2. Changing the MBDS Source-Code Compiler 
A change of compilers was experienced by the MBDS high-level code (by 


circumstance) each time a change of operating systems was made. In the original 
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MBDsS configuration the DECUS C compiler was used for nigh-level code which 
was developed on the PDP-11/44 computer (using the RSX-11/M operating sys- 
tem). For code that was developed on the VAX-11/780 computer (using the 
VMS 3.7 operating system) the EUNICE C compiler was used (EUNICE emulates 
a UNIX environment on the VMS operating system). For the second MBDS 
configuration. the UNIX C compiler was used for high-level code on both the 
VAX-11/750 (using the UNIX 4.2 BSD operating system) and the ISI worksta- 
tions (also using UNIX 4.2 BSD). In the third version of MBDS the DEC C com- 
piler on Micro-Vax IIs was used (using the MVMS 4.1 operating system). This 
same C compiler was used to develop high-level code for the VAX-11/780. Since 
executable-code generated for the Micro-Vax II] computer is upward compatible 
with the VAX-11/780, it was possible to develop high-level code for the Vax- 
11/780 on the MicroVaxs and then copy across the executable files. This avoided 
any risks of using yet another C compiler, and avoided using the VAX-11/780 for 
development purposes (since the VAX-11/780 was used for other purposes in 
addition to the MBDS research). 

Changes to svstem-source-code (as result of changing compilers) would 
normally be expected in sections of code which perform translator-environment 
processing. However this was not the case with the MBDS software. there were no 
changes required for code which performed translator-environment-processing. 
This is probably because the origin of the C programming language is closely tied 
to the UNIX operating system. cece oe most developers of C compilers (for 
any operating system) provide compiler libraries which are copies of the original 
UNIX C compiler library. 

There were some changes required in the MBDS high-level code which 


performed basic-process operations (as a result of the new compiler). These 
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changes were required when the MBDS software was ported from the second to 
the third versions (i.e.. from the UNIX C compiler to the DEC C compiler). 
Though the actual changes required were simple (and were needed in less than 
twenty lines of C code). the time required to determine the cause of the problem 
was considerable. Both compilers accepted the source code (they just interpreted 
it differently). so there were no error massages produced at compile time. Indica- 
tions of the compilers differences did not appear until the new executable files 
were run and the new version did not work! Keep in mind that a new compiler 
was not the only change which had taken place. This, along with the fact that no 
problems fad arisen from previous compiler changes. and that the problems were 
in sections of code which performed basic-processing (the least probable area), 
served to create a dificult debugging problem. 

The difficulties apparently resulted from differences in the way the two 
compilers assigned precedences when multiple C language operators appeared in 
one line of code ( the C programming language allows certain short hand coding 
constructs to save typing time). The only changes needed were to remove these 
short-hand lines of code. and rewrite them in a manner similar to the way they 
would be written in any other high-level language (e.g.. Pascal). From a software 
engineering point of view, the short-hand coding techniques should have been 
avoided anyway. since they tend to be very cryptic. making the resulting source 
code difficult to read and maintain. 

3. Changing the MBDS Operating System 

Portions of the MBDS software have run on five different operating sys- 
tems. In the original MBDS configurations the controller used the DEC VMS 3.7 
operating system, while the backends used the RSX-11/M operating system. For 


the second version of MBDS. both the controller and the backends used the UNIX 
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4.2 BSD operating system. In the third version of MBDs. the VMS 4.2 operating 
system was used for the controller. with MVMS 4.1 running on each of the 
backends. 

As was stated in the previous chapter. a change of operating systems is 
the most drastic kind of porting for any software system. The MBDS software 
changes required as a result of a new operating system accounted for the vast 
majority of work needed, both in terms of time spent and percent of the MBDS 
software which had to be modified. While all of the MBDS system-source-code 
which performed runtime-environment-processing had to be modified, the changes 
were isolated to just a few source files. This was a result of the abstraction and 
encapsulation techniques used by the MBDS designers. Therefore. it was easy to 
predict the majority of the changes which must be made to accomplish the 
porting. 

Some minor changes must be made to sections of the MBDS code which 
performed system-timing operations. These changes consisted mostly of changing 
the names of functions which were called (from operating system libraries), and 
rearranging the order of some parameters to those functions. The majority of the 
system-source-code changes must be made in the sections of code which perform 
communications. 

For the original version of MBDS three different methods of communica- 
tion were used depending on whether the need was for inter-computer communi- 
cation. intra-computer communication in the controller. or intra-computer com- 
munication in a backend. Inter-computer communication was accomplished using 
a point-to-point parallel communications link. In the backends. intra-computer 
communication (under the RSX-11/M operating system) was accomplished with 


shared memory techniques. For the controller. intra-computer communications 


(under the VMS 3.7 operating system) were performed using VMS mailboxes. 
When the MBDS software was ported to the UNIX operating system none of 
these communication techniques existed. 

Under the UNIX operating system, all communication (inter-. and 
intra-computer) was accomplished using UNIX sockets. This meant that all code 
which performed the communications had to be changed. Due to the virtual- 
interfaces which MBDS had set up. these sections of code were again isolated to 
just a few source files. There was also the advantage that the virtual-interfaces 
could accomplish all three types of communications with just one low-level driver 
(UNIX sockets). However. when the third MBDS version was implemented it did 
not use UNIX, so all the communications drivers again had to be changed. 

The third version of MBDS used VMS mailboxes (like version one’s con- 
troller) for Pr omputer communication in both the controller and the back- 
ends. This meant that the source code which had been used in version one’s con- 
troller could be used (virtually unchanged) for version three’s controller. In addi- 
tion. it could be used for the backends as well (with only minor changes). Inter- 
computer communications in the third version of MBDS were accomplished using 
DECNET. Since this technique had not been used in any previous MBDS ver- 
sions. entirely new communications drivers must be written. The virtual-interface 
techniques again isolated the changes to just a few files. 

The operating-system-command component of MBDS was rewritten each 
time MBDS was ported to a new operating system. There are in excess of twenty- 
five command-files used to manage the implementation of the MBDS software. 
So. while the required changes were mechanical in nature. they required a great 
deal of time to accomplish simply because of the number of files which were 


changed. Even though the controller for version one of MBDS ran on the VMS 
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operating system (like the controller and backends of version three). the controller 
software only represents about twenty-five percent of the MBDS software. There- 
fore. while some of the’command files from version one could be used in version 
three (with minor modifications), there were still a great many command files 


which were rewritten. 
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[i ww choot LOOK AT Tat MBDS PORT 


In this chapter we discuss the steps necessary to transform MBDS version 
two into MBDS version three. We examine the porting process in a chronological 
order, essentially presenting a journal of the activities used to move the software. 
A separate detailed discussion is presented of the changes made to the MBDS 
communications software (which underwent the greatest changes). First. lets look 


at the sequence of events used to accomplish the porting. 


A. THE SEQUENCE OF EVENTS 
Porting the MBDS software from one system to another has entailed several 


distinct phases. The major milestones in the sequence are as follows: 


e transfer the MBDS files (of source-code and operating-system commands) 
from the old computing system to the new one, 


e modify the operating-system-command files used for compiling the MBDS 
software. 


e compile the source-code files and correct any compile-time bugs which 
appear. 


e modify the MBDS intra-computer communications software, and implement 
an intermediate version of MBDS with a controller and one backend. both 
running on the same computer, 


e perform run-time testing on the intermediate system to ensure the actions of 
the implementation are logically correct (according to the MBDS design), 


e modify the MBDS inter-computer communications software to implement 
the final version (MBDS version three). 


e confirm the actions of the final version are logically correct. 


While some of these phases overlap to some extent. the porting sequence is clearer 


if they are considered separately. 
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The files of source-code and operating-svstem:-commands which comprise 
MBDS (version two) exist on one of the ISI] workstations. The first step in the 
porting process is to copy all of the files to one of the Micro-Vaxs, where the 
development of MBDS version three has been accomplished. Since the computing 
systems for both versions of MBDS are connected to a common local-network, the 
files are copied using the standard communications utilities available. 

Once the are were on the new system. the next step is to convert the 
operating-system-command files. Since the command files are needed to manage 
the compilation of the MBDS source-code, their conversion must take place before 
the compilation of the system begins. Each implementation of MBDS contains 
six independently executed programs (or processes) for the controller and five 
independent programs (or processes) for each backend. There is a set of com- 
mand files for each of the independent programs. One command file in the con- 
troller source-code (and one in each backend) may call all of the subordinate com- 
mand files. and in this way the entire set of MBDS processes can be created from 
the top level. The total number of command files for the controller and backends 
(in version two) is approximately twenty-five. 

The command files in MBDS version two are UNIX makefiles. These have a 
capability for tracking which source-code files have been modified (and which 
have not) since the last time a program’s source-code files are compiled and 
linked. Makefiles also allow the programmer to state which source-code files are 
dependent on other source-code files. Through makefiles. only modified source- 
code files are recompiled, and they (and files dependent on ‘her are relinked. 
Some of the MBDS processes require over thirty-five source-code files. and each 


shares some common source-code files with the other MBDS processes. Therefore. 
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the management of the MBDS software is easier. and modifications can be accom- 
plished faster. when makefiles are used. 

Version three of MBDS uses the VMS operating system which does not have 
a makefile utility available. The VMS operating system provides command files. 
but they do not have the capability of tracking source-code modifications and 
dependencies. Therefore, to use command files for managing the implementation. 
not only must all of the makefiles be rewritten but the logic of their organization 
must also be changed. This means that MBDS version three requires over fifty 
command files to manage its implementation, more than twice “aiNe number of 
makefiles used by version two. Program modifications also take longer since it is 
easier to recompile and link all source-code files needed for a program (even 
unmodified ones), than to manually keep track of which have changed and what 
files are dependent on them. 

In order to avoid the problems caused by not using makefiles. an initial 
attempt has been made to utilize the EUNICE environment (on the VAX- 
11/780). In EUNICE (a software system that emulates UNIX) makefiles can be 
used to compile programs which run on the VMS operating system. However. 
while the programs run on the VAX-11/780 (with VMS) they prove to be not 
downward-compatible to the Micro-Vaxes, which are used for the MBDS back- 
ends. (The Micro-Vaxs are designed to be upward-compatible to the VAX- 
11/780. but not vice versa.) Therefore, the makefiles had to be redone as com- 
mand files. 

The MBDS command-files are converted one set at a time. as each set is 
converted an attempt is made to compile the MBDS process. While it is known 
(because of the MBDS design) which files need changes, there is a desire to see if 


any unexpected compile-time errors might occur. No compile-time errors emerged 
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some warning messages have been generated because of variable naines which con- 
tain too many characters. These are truncated by the compiler but do not cause 
any problems (the truncated length happens to be long enough to maintain 
uniqueness). Once each of the processes is compiled, what essentially exists is a 
version of MBDS with program segments executable on the VMS operating sys- 
tem. but still only able to communicate with each other using the UNIX commun- 
ication facilities. Obviously, the next step in the porting is to modify the source 
code which performs communications. 

As we stated in previous chapters. MBDS performs oe types of communica- 
tion. intra-computer and inter-computer. With the UNIX operating system (used 
by MBDS version two) both types of communications are accomplished in the 
same manner. The VMS operating system (used by MBDS version three) uses 
different means to accomplish each of the two types of communication. The deci- 
sion is made to modify the MBDS communications software in two phases. In the 
first phase, an intermediate version of MBDS is created which utilized only one 
computing system, supporting both the controller and one backend. From a func- 
tional point of view. the controller and each of the backends does not know where 
the other components are executing. 

Since the intermediate version only used one computer, there is only a need 
to modify the intra-computer communications at that point. Version three of 
MBDS uses VMS mailboxes for intra-computer communications in the controller 
and backends (like the version one controller). For the intermediate version, the 
sections of code which normally perform inter-computer communications can cal] 
the same virtual communication interfaces as the intra-computer communications. 

When an attempt is made to test the intermediate MBDS version the first 


unexpected problems arise. After a considerable debugging effort the problem is 
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isolated to three lines of source code. The problem is ‘solated in the sense that it 
is known to occur in a particular line. but it is not obvious why it occurred. By 
all observations the code is correctly written. and it has functioned properly. as is. 
in version two. Eventually, it is suggested that the code might be correct to the 
human observer but is being incorrectly interpreted by the compiler. The lines of 
code in question use some short-hand coding techniques. which has apparently 
complicated parsing them. The lines of code causing the problem looked like this 
(the problem areas are in bold): 


while (msg_q|(*index)] != 0) 
data|j++] = msg q|(*index)++]; 


datalj]| = msg _q|(*index)+-+]; 

They are modified, to remove the short-hand techniques. resulting in the code 
shown below (note the need for two additional lines of code): 

i = *index; 

while (msg _q[i] != 0) 

data[j++] = msg q{i++]; 

data[j] = msg_qli++]: 

*index = 1; 
Once these changes are made the section of code functions properly, simular 
changes are needed in three other sections of the source-code. These are the only 
changes that have been required to get the intermediate version of MBDS working 
properly. 

The next step is to modify the inter-computer computer communications. 

Since the UNIX version does not have separate interfaces for inter-computer com- 


munications. these are not actually modifications. Instead, entirely new interfaces 
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must be created for VMS inter-computer communications. MBDs version three 
uses DECNET software to perform the inter-computer communication. These 
interfaces (as well as the ones for the VMS intra-computer communication) are 
discussed further in the next section. After the inter-computer communication 
interfaces are completed the only task remaining is to perform some final testing. 


No additional modifications are necessary to create MBDS version three. 


B. THE MBDS COMMUNICATION INTERFACES 

Before proceeding further with any discussion of modifying the MBDS com- 
munication interfaces. we first present a general overview of the MBDS software 
architecture and how it utilizes the communication interfaces. As we have stated 
before. each MBDS implementation has a controller and one or more backends. 
The controller is comprised of six processes, and each of the backends has five 
processes. In a normal implementation the controller (i.e., its six processes) is run 
on its own computing system, there is also a separate computing system for each 
backend. Since each process is an independently run program it has no direct 
connection to any other process, yet the processes must pass messages (informa- 
tion and data) to each other for MBDS to operate. Within each process there are 
the virtual interfaces for sending and receiving messages. it is these send and 
receive routines which must actually be modified whenever MBDS is ported. The 
send and receive routines only perform the intra-computer communication. 

Of the six processes in the controller only four are needed by MBDS for data- 
base operations, the other two processes are used for inter-computer communica- 
tion. The same is true for each backend, that is. only three of the backend 
processes are used for database operations. the other two are for inter-computer 


communication. These processes (in the controller and each backend) operate as 
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the virtual interfaces for inter-computer communication. To avoid confusion with 
the intra-computer interfaces we call these processes get-net and put-net (as 
opposed to send and receive). Excluding the get-net and put-net processes. all 
MBDS database-processes perform only intra-computer communication. The 


pseudocode for any MBDS database-process (at a very high level) looks like this : 


While MBDS is operating do 


Receive a message 
Perform any required processing 
Send any required response 


From looking at the pseudo code you might wonder how messages ever get from 
one backend to another. or from a backend to the controller. The answer is in the 
last line of the pseudo code, the key word is required. The required response may 
mean sending a message to more than one other process, if one of those processes 
is the put-net process then the message eventually goes to a process on another 
computing system. Therefore. the pseudocode for the put-net process looks like 
this: 


While MBDS is operating do 


Receive a message 
Put it to the appropriate process 


The appropriate process to which a message is put is always a get-net process on 


another computer system. The pseudo code for a get-net process looks like this: 


While MBDS is operating do 


Get a message 
send it to the appropriate process 


Now lets examine how the MBDS intra-computer communication interfaces (send 


and receive) have been modified to operate under the VMS operating system. 


oT 


1. Modifving the Intra-Computer Communications 

The controller for MBDS version one uses the same VAX-11/780 as the 
controller for MBDS version three. While version one runs on VMS 3.7 and ver- 
sion three runs on VMS 4.2, the intra-computer communication facilities provided 
by the two VMS releases are the same. Therefore, the MBDS version one con- 
troller communication interfaces can be used for the MBDS version three con- 
troller without modifications, and can be used for the version three backends with 
only minor modification. 

In the VMS operating system, intra-computer communication is accom- 
plished with VMS mailbozes. These mailboxes are virtual devices which can be 
created through the operating system. When a program calls the operating sys- 
tem to create a mailbox. the program must specify a logical name to be assigned 
the mailbox. The operating system then creates a mailbox. with the specified 
logical name. and provides the program with a logical channel to the mailbox. 
Once a mailbox is created messages may be put into it (or taken out of it) by 
writing to (or reading from) the logical channel provided by the system. If a call 
is made to the operating system to create a mailbox with a logical name that has 
already been used. no new mailbox is created. the operating system just provides 
another logical channel to the already existing mailbox. This is how different 
processes on the same computer can communicate. If several processes all use the 
same logical name in a create-mailbox call to the operating system, then they all 
share the same mailbox. 

The MBDS intra-computer communication (using mailboxes) is accom- 
plished by having each process in the controller (or backend) create a mailbox 
with its own logical name. and mailboxes with the logical names for each of the 


other processes in the controller (or backend). The logical names are standardized 
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for al! controller (and backend) processes. As we have said. if the same logical 
name is used more than once. multiple mailboxes are not created. Rather. only 
multiple channels to the mailbox with that logical name are created. Therefore. 
when all processes in the controller (or backend) have finished with their create- 
mailbox calls. there is one mailbox for each process in the controller (or backend). 
Each process has a logical channel to its own mailbox. and logical channels to the 
other processes’ mailboxes. The protocol that MBDS uses to make this scheme 
work is that processes can only read their own mailboxes, and can only write to 
other processes mailboxes. There is no need to write to their own. or read from 
any one elses. 

The MBDS version one controller's intra-computer communication 
software is used without changes for the controller in MBDS version three. To 
create the version three backend intra-computer communication software. it is 
only necessary to use a copy of one controller software with the controller erica 
names (for the mailboxes) changed to backend logical names. 

To create the intra-computer communications software for the inter- 
mediate MBDS version (i.e.. where the controller and backend run on a single 
computer together), one additional (temporary) change is made. An additional 
mailbox is created for the get-net and put-net routines in the backend and the 
controller. (Actually. only additional channels to existing mailboxes are created.) 
Normally. a controller process only has channels to mailboxes for controller 
processes. and backends only have channels to backend processes. For the inter- 
mediate version, put-net in the controller had a channel to get-net’s mailbox in 
the backend, and vice versa. This allowed the get-net and put-net routines to use 
the same virtual interfaces that are used by the send and receive routines (which 


perform all of the intra-computer communication). For the final version of 
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MBDsS (version three). put-net and get-net no longer use mailboxes for communi- 
cation. This is because the VMS operating system does not allow logical channels 
to be established to a mailbox in another computer. 

2. Creating the New Inter-Computer Communications 

MBDS version three. like version two. uses Ethernet communication 
hardware to connect the controller to the backends (and the backends to each 
other). However, from a functional viewpoint, MBDS version three’s inter- 
computer communication software operates more like MBDS version one (which 
used point-to-point communication hardware). This is because the way DECNET 
(VMS) communication software operates it does not provide a broadcasting capa- 
bility. DECNET is the operating system software used for the version three inter- 
computer communications. 

In the UNIX (Ethernet) environment all processes that wish to commun- 
icate simply associate themselves with the network. each process fea has a logical 
communication link with all of the other processes that are associated with the 
network. (This is much the same as when processes under VMS associate them- 
selves with a common mailbox, for intra-computer communication.) However. in 
the DECNET (Ethernet) environment each process must establish a separate logi- 
cal link for every other process it wants to communicate with, therefore. this is 
essentially (software) point-to-point communication. 

When using the DECNET software, all processes which communicate 
with each other are either source processes, or target processes. A source process 
is one that initiates a request to establish a communication link with another 
process. the target process is the one that receives the request. A given process can 
be the target for a communication link with one process. and the source for a 


communication link with another. The DECNET software requires that a target 
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process is in execution before its source process requests the communication link. 
A requirement like this does not exist for inter-computer communication in 
MBDS version one. or version two (nor does it exist for intra-computer communi- 
cation. in any version). Therefore, the logic for the put-net and get-net processes 
in version three must be completely changed. 

In order to establish, and maintain. communication under the DECNET 
software the get-net and the put-net processes must operate under the following 


constraints: 


e any process which is a target must be’executing before its source process 
attempts to establish communication. 


e if a process is to have multiple communication links, where it is a target in 
some cases. it must be capable of maintaining communication on established 
links. while still waiting for (or accepting) any links where it is the target, 


e a target process must inform the operating system (through DECNET) of 
the network name it is using, so that DECNET can properly route connec- 
tion requests, 


e a source request must know the network name for all of its target processes. 
and it must know the name of the computer (the nodename ) that each tar- 
get executes on. 


e a process must know the total number of communication links it should 
have, how many it is: target for. and how many times it is a source. (This 
is because MBDS conngures the number of backends to be used. on-the-fly. 
when it is started.) 


Now let us review how the get-net and the put-net routines for MBDS version 
three were organized to meet these criteria. 

In the MBDS controller, both the get-net and the put-net processes are 
always source processes. Therefore, when MBDS is initially started. the controller 
processes are executed after all of the backend processes are executed. This 
satisfies the target/source ordering for the controller-to-backend communication. 
As soon as the controller is informed (by the user) how many backends are to be 
used the get-net and the put-net routines can begin establishing (requesting) com- 


munication links. Since the controller (get-net and put-net) communication 
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routines are never targets. they do not have to inform DECNET of any network 
names (they do not need network names). Also. since they are never targets. they 
do not have a requirement to accept a connection request while communicating 
(they never accept connection requests). When requesting the communication 
links, get-net and put-net know the names of the processes they communicate 
with because the MBDS process names are standardized. In order for them to 
know the computer systems (nodenames) that the backends are executing on, the 
nodenames are standardized as well. 

Each nodename consists of a character string that ends with a number 
(e.g... CSMV1. or CSMV2), only the numbers at the end are different. The con- 
vention used by MBDS is that, if only one backend is used, it is on the computer 
with the lowest nodename (i.e., CSMV1). if multiple backends are used they are 
on the computers with the lowest consecutive nodenames (e.g., for three backends: 
CSMV1, CSMV2, and CSMV3). As soon as the controller routines know the 
number of backends, they can construct the proper nodenames. 

For the MBDS backend-to-backend, inter-computer communication the 
backend get-net processes are always targets. and the backend put-net routines 
are alwavs the source. Remember that backend put-net processes are targets for 
controller-to-backend communication. they are the only processes which perform 
both as targets. and sources. depending on the situation. Since there is always a 
single controller. the backend put-net process knows it is a target for a single com- 
munication link. The backend put-net process does not begin requesting links 
(acting as source) to the other backends get-net processes until after it has 
received its first message from the controller. By convention, this first message is 
always the number of backends to be used. The put-net process then knows how 


many communication links it must have. and where it is the source. The put-net 
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process forwards this message (using the intra-comiputer communication) to its 
respective get-net process and then the get-net process knows how many times it 
must act as a target for a communication link. The backend put-net routines 
determine nodenames (for the other backends computer systems) in the same 
manner used by the controller. When the backend get-net and put-net routines 
are first executed. they inform DECNET of the (standardized) network names 
that are being used. 

Because the backend communication processes (get-net and put-net) act 
as target tasks with multiple communication links, they must be capable of main- 
taining the communications on any established links while waiting for (or accept- 
ing) connection requests. They accomplish this by using VMS mailboxes. these 
are the same types of mailboxes used for intra-computer communication. How- 
ever. in this case. the mailboxes are not used for MBDS messages. but are used for 
DECNET status information. . When a process uses DECNET to perform com- 
munication it establishes a logical link to DECNET. This is in addition to the 
logical links for the other processes that it communicates with. Any time a pro- 
cess establishes a logical link, the process has the option of associating a mailbox 
with that logical link. One mailbox may be associated with multiple links. 

If a communication link has a mailbox associated with it. DECNET 
places network status messages {about that link) into the mailbox. These status 
messages may include information such as the fact that DECNET has a connec- 
tion request for a process. the fact that an established link has received a message, 
or the fact that a process on the other end of a communication link has discon- 
nected itself. Therefore. the backend communication processes can handle multi- 
ple links by associating a single mailbox with all of their communication links. 


Each time the process completes an operation (e.g., putting a message, getting a 
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message. or accepting a connection request) it then reads its mailbox. The next 
message in the mailbox determines what operation the process must perform next. 
DECNET automatically queues multiple messages in the mail box. If a process 
mailbox is empty the process waits until a message arrives, that is, an empty 
mailbox means there is nothing else for a process to do. 

Mailboxes are used for managing multiple connections by all of the 
MBDS inter-computer communication nnocerres which act as targets. or as 
message-receiving processes. Therefore, the put-net process in the controller is the 
only one that does not need a mailbox to manage its communications (it is never 
a target. and only puts messages). By convention, any time a process puts an 
inter-computer MBDS message to another process it also puts a DECNET 
notification message to the same process (these are optional with DECNET. and 
not generated automatically). The MBDS message goes on the logical communi- 
cation link, and the notification message is placed (by DECNET) into the mailbox 
for that communication link. at the receiving process. If the DECNET 
notification message were not sent the receiving process would never be prompted 


to look at the communication link for a message. 
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V. SUMMARY AND CONCLUSIONS 


In this thesis we have focused on three major areas of work. First, a para- 
digm for a software system has been presented. and we have examined how the 
components in the paradigm relate to the portability of the software system. Let 
us review the general issues of software portability discussed in the previous 
‘chapters. We have presented a paradigm for a software system which shows that 
there are two main components to any software system, the system source code 
and the operatings system commands used by the software system. Each of these 
main components has additional sublevels. For the system source code there are 
the sublevels of machine code. assembler language and high-level code. The sub- 
levels of operating system commands are, basic commands, command files, and 
utilities. We have also stated that there are three parts to a computing environ- 
ment which a software system interacts with, the hardware, the translator (used 
by the source code for the software system) and the operating system. Finally, we 
have stated that. the components of a software system interact with the parts of 
its computing environment through three types of processing, basic processing, 
translator environment processing, and runtime environment processing. 

Our analysis showed that the ease with which a software system reacts to 


porting is determined by three factors: 


e the levels of system source code and operating system commands used to 
construct the system. 


e the types of processing which the software system performs, and 
e the parts of the computing environment which are changed. 
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In general. a software system is highly portable if it uses only high-level code. and 
if it avoids runtime environment processing whenever possible. 

The second focus of the thesis has examined how well the MBDS software 
stands up to porting. To construct its three versions. the MBDS software has 
been subjected to all three types of porting. Each time the system was ported, 
MBDS ran on new hardware. had a new operating system and had a new transla- 
tor for its system source code. Despite the drastic changes in its environment, 
MBDS performed extremely well each time it was ported. In neither case did the 
fundamental MBDS design require modification. This can be attributed to several 
factors. First, the MBDS software is written entirely in high-level code and the 
use of runtime processing has been avoided except where absolutely necessary 
(e.g., communications and disk input/output). Additionally, any processing 
which might complicate portability has been buffered in MBDS through the use of 
abstraction, encapsulation and virtual interfaces. 

The third focus of the thesis has involved the details of the MBDS porting. 
The major work of porting MBDS has involved modifying the sections of code 
which create the virtual interfaces. The interfaces themselves have not been 
changed, only the way in which the interfaces accomplished their jobs are 
modified. These changes have involved the MBDS communication software. For 
the inter-computer communications, the MBDS version one software has been 
modified to create MBDS version three. This intra-computer communication is 
accomplished using VMS mailboxes. For the inter-computer communications, 
entirely new communication software has been created in MBDS version three. 
The VMS DECNET communication drivers are utilized for the inter computer 
communications. (Source code for the new inter-computer communication 


software is contained in the appendixes to the thesis.) 
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In addition to modifying the communication interfaces. creating MBDS ver- 
sion three has also required modifying all of the operating system command files 
used to manage the software. This involved rewriting the UNIX makefiles (from 
MBDS version two) as VMS command procedures (for MBDS version three). 
Rewriting the command files has been the most time consuming task in the port- 
ing process. 

Overall, MBDS has proven to be easily Sortable. With the exception of some 
minor problems caused by the way the new compiler parsed some lines of code (in 
MBDS version three), all of the modifications required to port MBDS have been 
known before the porting began. Additional information on the portability of 
MBDS can be found in [Ref. 1] which deals with the process of porting MBDS 


version one to MBDS version two. 
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APPENDIX A - THE MBDS CONTROLLER GEIR ED Ot Cine Gr 


OK OK KK KR KR KK DKA FO OR OR KOR OK A OF OF OK Ke KR OR OK KK KH KK KK KK K A 


KKK KKK KKK KK KK KKK KK KK KK KK KK KK KK KK KK KKK KK 


Os 

/" 

fi VAX / VMS ~ Greer pee 
io a 

/ 


include <stdiogh> /* S twantdicgiduls/O deiigens tacene * 
Fimeludemeasisdet .h-= /* WMS return status @oacam 7 
2-7) Mc eucien mh © Chet eae: /* VMS 1/O return codes “yi 
#include <msgdef.h> /* DECNISiSms ¢ detini t momen. / 
#inc lude s<dvy idea ein. / "NMS deviée det tritroncua= 
#include "“commdata.def" /* MBDS common defs i 
tine lude "ms gwd /* MBDS msg-type defs ie 
#eyme |aG € ai laos aedtcnn as: /* MBDS compile flags oi 
define MAXBE 16 /* max num of backends */ 
char netbuf {[MSGLEN] ; /* network buffer eT 
char mbxbuf {[MSGLEN] : /* mailbox buffer mal 
char ms g {MSGLEN] ; /* MBDS-msg buffer af 
short net chan: /* chanme |. 1.0 DEC a7, 
short mbx chan: [Seana estrone il box a 
short be chan{MAXBE + 1]; /* chan’s to backends */ 

7 /* backend 0 is not used */ 
short be dev{MAXBE + 1]; /* device num of chans */ 
short NoBackends: /* the num of backends */ 


struct msg hdr head; 
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Mat i. |) Sloop xAmicie x 
Sropoy s: . /* system running flag ”*/ 


char NoBEs |NoBElength + 1]: 


/* init intra-computer communication */ 


mbinit( G PCLC ): 


#ifdef EnkxFlag 
Paemtd (7 EeitermeaGPCh nih \p, 


-end if 
/* get the number of backends */ 


mercer pr flag 
printf("Getting number of backends\n"): 
endif 
receive(msg. &head): 


foeucet pr flag 
m prnt(msg. &head) ; 


zendif 
if (head.type != SetNoBEs } 
{ 
Pend " Enger in GPCLCw first msg must be "): 
Pommirl Of type SetNoBEs ** \n"™)* 
printf("** Type = %d **\n". head.type): 
m prnt(&msg. &head) ; 
sleep(DELAY) : 
exit ( ) 


} 


/* Extract the number of backends */ 
fermemer—O (| ( Nobis | =-msg)i|)} ‘=MPro>}: i++): 


NoBackends = str to num(NoBEs}: 
ifdef pr flag 


printf("Number of backends= %d\n". NoBackends) : 
ema 1 T 
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/* Init network connections to P rCl Seine pacnemdeus a 
net Init | Noack emacs 


StopSys = FALSE: 
while (| stopeacs =) 
{ 


get message(msg.&head) ; 


Swieteh. | lemidest prem 


{ 


/* msg type for msgs from DMgt (BEnds) to IIG (Cc tien |e, 
case(ReqForNewDescld): 
head.receiver = [1IG: 


break: 


Case Chus Id): 
hemd.rece ive ta— alia. 


Dberecae 


/* msg type for msgs from RecP (Binds) tower (cima 
case(BC Res): 
head.receiver = PP: 
break. 


case (BC AO Reg - 
head.,receiveru—) 
break; 


/* msg type for msgs from RecP {BEnd-= )tceheqre (cnt. | yee. 
case(RetFetCausedByUpdRes }: 
head.receiver = REOP: 
break: 


case(RecChangedClus): 
head.receiver = REQP: 
break: 


case( NoMoreGenIns }-: 


head.receiver = REQP: 
break: 
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Mmemmioe tf. pe for mses from BEnds to Tl VILE ie 


Case Ean OT): 
head.receiver = TI: 


preak: 


case(ErrorFree): 
head.receiver = TI; 


break: 


case(GeTimes): 


Readeerece iver = II; 
[eer Ko 

aston eh enn yar cee) 
Nheaawrecei er — 11: 
break; 


case(Stop): 
Stropoys ="ORUL: 
break; 


default: 

“printf("Invalid message type "); 
printf("encountered: %d'in",head.type): 
exit. Shace tunel vag 


\/* end switch */ 
Poe Stop ays | 


heaaesenadere— Griecec. 


send(msg, &head)}) : 
reecdet pr {lag 
m prnt (msg, &head): 


} 


\/* end while */ 


zendif 


miitdeft EnExFiag 
Preimet exit  GPel \n' |i. 
~emd 1 f 


} 


ol 


/ 
get message(mptr.hptr} 


ean “Th Oneare 
Struct mse adres wee, 
4 
int Stat. 
msglen, 
Tecnica 
ee 
sion teombied 
char rcevbuf |MSGLEN + 1], 
Pmt but | 24 ule 
tampiet F | Onn 


SLOT teins @ te cs 


ifdef EnkxF lag 
printf("Bnter get mecace (a 9) 
tendif 


/* “Check mailbox for message notices */ 


read mbxi(mbx bum e 


/* Read the message */ 
read net(rcvbuf. mbxbuf) ; 


/* Get the header ini cumagiene . 3 
k=0 ; 


/* get sender */ 
for (j=0O: j3 < 3: j+t) 


tmpstr[{j] = revbuf [k++] : 
timp sete | Oe 
hptr->sender = str t0 num tmporne 


/* Set teceiver = 7 
for (j=0O: j < 3: jt) 
tmpstr{j] = revbuf[k+4] : 
tmps tr — soe 
hptr->receiver = str to gmam(aumpon mee 


o2 


/* routine to get the next message from the network 


Peecet the type —/ 
for (j=O: j < 3: jot) 


tmpstr[j] = revbuf [k++]; 
tapotr| j| =  \0 ; 
Dota type — str to mum(tmpstr) ; 


Sider pr tlag 


Mp Pevbwt. hptr ) ; 
zendif 


/* copy the message */ 
=e | 


while ( (k < MSGLEN) && (rcevbuf[{k] != EOMsg) ) 
mptr|j++| = revbuf [k+4] ; 


mptr{j] = revbuf{k]; /* get EOMsg */ 


if (k >= MSGLEN) 
prenatal! "> Value of MSGLEN ") ; 
Dutt Tsiould be Cinereased “""**\n") ; 
z=ifdef EnExFlag 
pee he Soci gle hemes sage \'™)", 


eendif 


} /* end get message a 


ood 


/* Routine to check the mailbox 10T messace™ nowpeccu.: 


read mbx(buf ) 


Ciaeten (iene 
{ 


short msg rec; 
short Sota. to. 
short iosb([4]; 


#ifdef EnExFlag 
printf("Enter read mbx\n"}; 
tendif 


m5 2c PAt See 


while? ( ' ms ¢ rele) 
#ifdef pr flag 
printf("Calling qio, read mai bongs: 
endif 


stat= sys$qiow(0, mbx chan, 10% READVBLK. 


iosb, 0.0. buf, MSCEEM 0.0.0.0) - 


7 1 chou wae sammlenean es 
printf (“Re t umd ai wgomecqhic me eiueg)e: 
ftendif 


if ((stat != $S$ NORMAL) || (iosb[0] != SS$ NORMAL)) 


{ 


printf("** Mailbox read error. stat= %d 


(Ax) ae 


printf ("“iosb|0|)= Yoder | ets a ee ee 


Vos b 0} . 
éXit <p raee finely) e 


} 
switch (buf [0] ) 


case MSGS INTMSG: 


{ 

msg rec = PRUE; 
bine k= 

} 


o4 


iosb[0]): 


easemusGs CONNECT: 
up 
l | 
DigiaG? | Meee uworkmaonnect lon") : 
poernt P(eaqwes ted." a) - 
Diet GeO mc hovelde: monte) : 


Brant, HeGemvenconnect req s "Ain" ) ; 
oe ae etre crummy |), 


} 


case MSG CONFIRM: break: 


default: { 
. Dretintii! = “ Network gemmor, ') 


Pre emnbec a nO eden ox) on 
baie O17, baie): 


painters marc ceitiel loyal 


} /* end switch */ 
foe end while */ 
+#ifdef EnExFlag 
Peet Exit read umbsc\n” |; 


endif 


peej end read mbx */ 
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/* Routine to read a message from a backend ~*/ 
read net (revbul sembxbnt) 


ehar “rey bill mb roimee: 
{ 
Shor t weet 
BEnum, 
intr eo 
Sila. Ge, 
iosb{| 4]: 


#ifdef EnExFlag 
Printt( ENnvere,ead ile mene a).. 


endif 
unit= mbxbuf: 
for (BEnum = 1: be dev{BEnum] != unit{[1]: BEnum++) 


if (BEnum = NoBackends ) 
{ 
De ate 
print("read net with. 
printf("*** Searched through %d backends."): 
OK OK | tt 


prince 0 Sees uniaye 
exit gracefully(); 


} 


yes Cannot locate sumit emunpe rt oO. sll 


* * HK | 1 : 
ni als: 


} 


#itdet Spr et ae 
printf("Calling qio read from backend “d\n” . BEnume 


#fendif 


fune = I10$ READVBLK; 
stat= sys$qiow(0, be chan{BEnum]., func. iosb. 
0.0. revbuf, MSGLEN. 0.0 J0more 


#1 idet “pie uae 


printf("Returned i Pomme que) least. 
#endif 


06 


Meeats — Soo NORMAL) jj (iosb)0), ‘= SSS _NORMAL) ) 

{ 
pena (" Read error be chan %d. stat= %“d(%x). "): 
Pemeee wOosb Ol = cd (7x) “en”. BEnum. stat, 
Sat lost |W) emiosio| | ): 


xr * 


ccomume race fully | ji, 


} 


miidet EnbkxF lag 
Dnci( Pxit read net \n” }\- 
#endif 


faa memd read net ~/ 


a7 


/* Routine to initializ Deemer inks) tcme mes eo ac ecm 


net init (NoBEs) 


int NoBEs: 
{ 
lonet S tiaetea 
short ioe bide 
char nodespec[128]. tmpstr[5] ; 


Struct esamy 
ieee etn 
@ Nae Ort me 
MONE 


netnam = { 5. a 
ncb = (90). Wmodicresmercun 
netmbx = { 6. “NETMBX" }: 
long dvi umeisraol 
Sh omt Gy aie Teenie (ate 
/* structure to get unit numbers (or cham Ss itoe mc ee 
Struc { 
short (lem /* bDuitier seme th gy 
short code: /* item code i 
long “Ter ar /* addr to return unit wou 
short “unitlen: /" lene yh oie 7 
long Till /* end of descriptor ah 


} 
dvi = {4, DV 1S SUNT reed. area dviunit len 078 


ifdef EnkxFlag 
Printe(: Enver megan ve aie 
#endif 


/* @reate agmailbosmae 
stat=sys$crembx(0. &mbx chan. MSGLEN. MSGMAX, 
OF70> Cne tmboe 


if (stat != SS$ NORMAL) 
{ 
printf("** Brror ered tain oe mamlD oc mae 


printf("stat= %d (7x) 7° Vn Ss tape enone ee 
exit (2 tT ace tule 


} 
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fee scien channels to the net 
f 


or(i=l:; i <= NoBEs: i++) 
{ 
stat= sys$assign(&netnam, &be chan{i]. 0. &netmbx): 
if (stat !'= SS$ NORMAL) 
{ 
Pama - Error in assign be chan %d, ") ; 


Demeter | Stat= ~d (4x) «ns, l,stat.stat): 
eeaitepracetul ly ( ) ; 


fe oeend for ii.” / 


/* Establish logocal link */ 
for(i=l; i <= NoBEs; i++) 


feeb ld network connect block */ 
smepy i nodespec , “CSMV") ; 

mumeto str(1, tmpstr) ; 

strcat (nodespec. tmpstr): 


Sereats(nodespec, "::\"0=PPCLB\"") ; 
suude!l pwr tlag 
printf("backend %d nodespec, \"%s\"\n", i. nodespec): 
zendif | 


nceb.len= strlen(nodespec) ; 

/* Request the connection * 

stat= sys$qiow(0, be chan{i], IO$ ACCESS. iosb. 
0,.0,0, &ncb. 0.0.0.0): 


if ((stat != SS$ NORMAL) || (iosb[0] != SS$ NORMAL) ) 
{ 
pimn("** Access err<er be chan Ad, stat= “d "); 


Peet (cox), 10osb/O|= Yd (%x) **\n". 1, stat, 
Seaeeeos hb | 0). 1osb | 0| }; 
eomueeracefully(); 


j 
fee end for i */ 
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Get unit numbers for the channels */ 
(i=l; i <= NoBEs: i++) 


at= sys$getdvi(l. be chan[i]. 0. &dvi.iosb.0,0.0): 


t 
f (stat != $S$ NORMAL) 

{ 

printf("** Error getting channel mumber s1or spies 

printf("%d. stat= %d (cx) me eens Ga tee 

exit gracefully({); 

} 
sys$waitfr(1) 
if “Forib ©); 

{ 

printf("** Error gettime © ivanmed a mgumb come ee 

printf("BE Ad, iosb|Q= Adc) =n 
1 OS DIO |S axis 0 ae 


= $$$ NORMAL) 


exit graceim@iinid) 
} 


be dev | iq) =) "da. iku at. 


ff * “end “fOr 


#ifdef EnExFlag 
Printe (Ex 1 oieme tia ae 
#endif 


} - f* ‘Eid gages Sei eee 
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ero ime to disconnect ai! network links i 
aisconnect |) 


Muto State. 1: 


#ifdef EnExFlag 
Pemiter( Enter Disconnect \n” } ; 
tendif 
for (i=l; 1 <= NoBackends; i++) 


{ 
mee: pr ilag 


Pant it Misconnectine backend “d\n”. 1); 
emia ft 
stat= sys$dassgn(be chan[i]): 
if (stat != SS$ + NORMAL) 
poamts (| Dassign Brmoneior backend Yod, ") ; 


Dt  stat— wd (%x) “*\n".i.stat. stat): 


} 
ifdef EnExFlag 
peat (Exit Disconnect \n" } ; 
fendif 


fee end disconnect */ 


/* Routine to close network connections. then abort */ 


Peaiteeeraceiully() 


{ 
sleep(DELAY) ; 


disconnect(); 
exit(); 
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APPENDIX B- THE MBDS CONTROLLER FU 1NEL SOU Cee 


[Roe Re ee eee 


* = 
[ VAX / VMS "92 0’ celme 7 
* * 


[RE ee 


© 1 ie [tid equa Caro ite /* Standard 1 /O detain 1 witon 577, 
#include <ssdef.h> /* VMS return status codes */ 
#include <iodef.h> /* VMS I/O return codes a 
#include <msgdef.h> /* DECNET msg definitions */ 
#include "commdata.def" /* MBDS common defs a 
#include "msg.def" /* MBDS msg-type defs auf 
#ine lude  —" f Warceseediesiey /* MBDS compile flags 4) 
#include "beno.dcl" /* backend num dec] * | 
#define MAXBE 16 /* max num of backends */ 


#define TRUE 1 
+#define FALSE 0 


char net buf {MSGLEN] ; /* network buffer | . 
char msg |MSGLEN] : /* MBDS-msg buffer : 
/* DackKendy 0) 1s @iet used: 


short be dev |MAXBE + 1]; /* device num of chans * 


/ 
/ 
short be chan|MAXBE + 1]; /* chan’s to backends */ 
/ 
¥ / 
short NoBackends; /* the num of backends */ 


Sit tare t msg hdr head; 
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main ( } 
{ 
Micon omonoys.1.).k: 
chart WoBEs|NoBElength + 1 | :; 


#iidef EnExFlag 
rote Emter PPCL\n"” } ; 
end 1 f 


/* init intra-computer communication sy 


Ripimit PF PCLC }; 


/* receive a message from a controller or 
/* task into ppel’s mailbox ) 
receive(&msg[0]. &head) ; 


/* The first message should type SetBEno. */ 
mi( head. type != SetNoBEs )} 
{ 
Pose ) Error in PPCL. Ist message ") ; 
printf("must be of type SetNoBEs" ); 
printf( " Type = %d\n", head.type }; 
msend(dasg/0]. &head): 
abort():; 


fees ernd num of BE to GPCLC */ 
head.sender = P Pere. 
head.receiver = G PCLC. 
send(démsg[0]. &head) ; 


oe tract themNeBackends */ 
omer O.) j—0.) (NoBEs |) |= mse ik]) t= ~,0°; 
k++. jtt ); 
NoBackends = str to num( NoBEs ): 


Keeeat 


ebometia) ize conmectnoms toubackends 7 
net init (NoBackends) ; 


/* send BACKEND NO and NoBackends to backends */ 


/* Change the message type */ 
head.type = SetBEno: 


63 


} 


/* send the mss Towencims 
for (i=l: 1 <= NoBackends: 


a 
/ 


1 = 


/* Put the backend number 
len num to str( (i), NoBElength, é&msg[k| 
= EOMsg ; 


msg{k + NoBElength +1] 
/* send the msg to the 


head rece liven — CG emeiner, 
put message(msg,&head. 


} 


1 + 1) 


into message 


specified BE */ 


hh 


/* receive message frompawiceont, omsle name 


/* task into ppel’s maz Nb 
receive (a&msg/[0], &head) ; 


StopSys = FALSE: 
while ( 'Stopeayvs 9) 


{ 


/* send the msg to each BE 
for (i=l: 1 <= NoBackends; 


{/* Send Site msg tho. ithe 
put message (msg.&head. 


} 


if ( head.type = Stop } 
Stopsys = TRUE. 


else 


/* receive the next message 


*/ 


l= 


specified BE */ 


ile 


7 


i + 1) 


* 


get message( &msg[0]. &head); 


}/* end whi lems 


exit gracefully(): 
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ee ae aces — 


/~ routine to send message over network to a backend */ 


pueeines Sage (mptr.hptr.BEnum) 


ehar erp tr; 
Smee tmse hdr “hptr: 
int BEnum: 
{ 
int stat. 
msglen, 
TC). 
ie Kk; 


mort iosb(4j ; 
char sndbuf |[MSGLEN + 1], 


intbuf{[2} = "\O", /* null message */ 
Papisiten | ol | 


zifdef EnkExFlag 


prime “Enter put message \n") ; 
zendif 


hptr -> sender = P PCLC; 
hptr -> receiver = G PCLB; 


k=0 ; 
/* copy header into message to be sent */ 
fomeouuimeto str(hptr->sender, 3, tmps ti): 


ik ( 
Pongo i < 3. jp) 
sndbuf{k++] = tmpstr([j]; 


Cima tO Strihptr-ereceiver. 3. tmpstr ) ; 
Come =O8 8) < 2.) )tet) 
sndbuf [k++] = tmpe tt jie 


Cenum to striniptr->type, 35 tmpstr) ; 
for —0- Wea j++) 
sndbuf[{k++] = tmpstr([j]; 
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/> copy the ’memisace (a 
j=0: 
while ( (k < MSGLEN) && 
((sndbuf [k++] = mptr[jt++]) != EOMsg) }: 


if (k >= MSGLEN) 
printf("***** Value of MSGLEN "): 


printf ("should be tm@mermeed 9 9° einue 
msglen = k: 
/* send the message */ 


# ifdef (pte Ware 
Prime’ ( eaten qio write to backend %d\n", BEnum) ; 
m pont (snd bmiiemenper 

#e: dif 


func = [03 WhRiteveric 
stat= sys$qiow(0, be chan{BEnum], func. cae 0407 
- Sia o ut. ise lens "O. on Ones 
+ Vtedeert Spee. k lear 
printf("Returned from qio, write\n"): 


ftendif 


if ((stat != SS$ NORMAL)||(iosb[0] != $S%$ NORMAL) ) 
{ 
Print ht") Wr 1 tee to le moira wd, stat= “Ad i") ; 
printf("(%x), iosb{O]= %d (%x) **\n", BEnum, 
Stat, Stat, TosbiO) © “VvosbPOiam 
€X1U 6 hac eames \e 


} 


/* let recenger know msg ise themen 7 
#ifdef pr flag 
printf("Calling die, ingen cup im oe 
#endif 


func = 10$ - 10$M INTERRUPT; 
stat= sys$qiow(0, be chan/[BEnum], func, iosb, 0, 
It Dip ee 0 0 
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=ifdef pr flag 
Det hetarned irom qio, interruptsn" ): 
#endif 
if ((stat ‘= SS$ NORMAL) || (iosb{0] !'= SS$ NORMAL) }) 
{ 
Peis interrupt error be chan %d. "); 


printf("stat= %d(%x), iosb/Oj/= %d(%x) **\n", 
BENUm. Stata State 105b/014 “10 simlO | ) : 
pores tacetul ly ( 


} 


tide? "BalxF lag 
printf("Exit put message\n"): 


#endif 


} 
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/* Initializes Decnet links to each of the backends / 
net init (NoBEs) 
int NoBEs:; 


{ 


emt Soa le 
short tos apa 
char nodespee|128|= ssnpst1)omm 


struct sd { 
int: (dens: 
char “per. 
} 
net nam: — oo, “ Nb D ae 
neb = (0, nedesmeci = 


#ifdef EnExFlag 
Pr im fie eee gol et oe ol 
#endif 


for(i=1l; i <= NoBHs: i--+) 


j/* @ssign a chanme ls tomtme etme 

stat= sys$assign(&netnam. &be chan{i]. 0. 0); 

if (stat != SS$ NORMAL) 
{ 
print?("** Error Gn assienbemmamams clele 
printf("stat= %d ((%x )O = ne tte ere 
Sante Tea eremiaiy he levalln lee 
} 

} 


{/* Establish ogo cas lmemmn «) 
for(i=l; i <= NoBEs: i++) 


/* build network connect block */ 
strepy (nodespecme «on aa 

num to str(i, tmpstr): 

streat (modespec mumps te 


streat (modespec. ">: \3@lCCrCLa ae 
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Peeece] spite lag 
mom backend “%d nodespec. "%s " n". 1. nodespec): 
zendif 


neb.len= strlen(nodespec): 


/* Request the connection * 
stat= syssqiow(0. be chan{i], IO$ ACCESS, iosb. 
0=0.05 eneb, 0.0.0 70) 
if ((stat != SS$ NORMAL) || (iosb[0] ‘= SS$ NORMAL) ) 
{ 
printf("** Access error be chan %d, stat= %d "); 
Perm (oe), tosh |O)|—= %d (%x) **\n!, i, stat, 
Spi tos 10sb/0)) ; 
Sait egtacet ul ly{ |i; 


} 
aw emi ofor.i ~* / 


#ifdef EnExFlag 

Dime eet met init \n 
¢endif 
} 
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/° routine to disconnect 411 metywor) iii ee 


disconnect()} 


{ 


int Stact -aeelee 


#ifdef EnExFlag 
print? (” Enver Disconmeen a). 


#endif 
for (i=1; i <= NoBackends; i++) 


f 

#1 ft Get ce Pela 
printf("Disconnecting backend %d\n", i); 

#endif 

stat= sys$dassgn(be chan|[i]); 

if (stat t= SS gone 

printf("** Dassign Error for backend %d, "): 

printf("stat= Yd (%x) * “en er Ssitataeceee 


#ifdef EnExFlag 
printf ("Exit Disconnect nm vm 


#endif 


} /* end disconnect */ 


/* Routine to close network ‘connections then) abom 


Sly eeaesn willy | 


{ 
sleep(DELAY) : 


dwscommecii je 
CX i titalle 
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meow, C- THE MBs BACK ESD GET-NET SOURCE CODE 


A I sk eS tet 
ine i 
iS Vi rAd ee aes G rae ls, 1B ‘i 
* - * 

* 


ea a ee Ree 


¥- 


=include <stdio.h> 
#include <ssdef.h> 
include <iodef.h> 
+include <msgdef.h> 
zinclude <dvidef.h> 


“Sotamaanan!/O definition 
* VMS return status codes 
* VMS I/O return codes 

* DECNET msg definitions 
* VMS device definitions 


e + & 


—,,_,_ Ta Ta TT 


include "commdata.def" /* MBDS common defs : 
#include "msg.def" * MBDS msg-type defs . 
sumelude "flags.def" /* MBDS compile flags : 
+#define MAXBE 16 /* max num of backends * 
char netbuf [MSGLEN] ; /* network buffer . 
gina r mbxbuf [MSGLEN] ; /* mailbox buffer : 
char ms g |MSGLEN] ; /* MBDS-msg buffer Fi 
short net chan; /* channel to DECNET 

short mbx chan * channel to mailbox 


short be chan {MAXBE lie chanaemeto backends 
/ obactendmon is control ler 


an AG 


short be dev|MAXBE + 1]; /* device num of chans 
short NoBackends: /* the num of backends 
short next chan = 0: (je iimemmext avail chan 


x * * 


SS SS ——— ee To TM TT TTT 


etc t sd { 
ite |) en: 
iia Tan pt oT: 
a) SS Um imnedeccriieinonsm= nom. ) ~ / 


/* the network device name 7 
Tee TERT —= (eg MNEs ome 
/* the mailbox name Gey 


netmbx = { 8, "G NETMBX" }; 
Spr wc t msg hdr head: 
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main () 


{ 


int Step oaese /* system running flag */ 


#ifdef EnExFlag 
print ti] VimtersGePClE nae 
#endif ° 
/* init intra-computer communication ey 


initst ( Geers); 


/* set up to use DECNET 7 


eta te 


StopSys = FALSE; 
while ( !StopSys ) 
{ 


. get a message from the network */ 
get message(émsg[0], &head): 


/* send the message */ 
set header(); 
if( head.type = Stop ) 
/* exit from MDBS aah 
Stopsvce— I[RUE, 


head.receiver = RECP;: 
send(msg, &head) : 


head.receiver = DM: 
send(msg. &head): 


head.receiver = CC: 
send(msg., &head}): 


héad -reeern er. — MOI, Bi 


send(msg. &head): 
} /* end if part */ 
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eo cme tied.) pes —— Se t BEnomm 


{ 

/* set number of backends. oy 
/* and this backend number. a, 
feeeGe Ce titseli > w does NOT care */ 
head smece iver i= RECEP - 

send(msg. &head): 


head.receiver = DM: 
send(msg, &head ) ; 


head 7reécei1venes— €C. 
send(msg, &head): 


Wead. receiver = Peele. 
send(msg. &head) ; 


else if( head.type = 


NewDB || /* create new database */ 
head.type = 

Template | | /* create new template */ 
head.type = 


SelectDatabase) 

/*assign database to user “*/ 
{ 

/~ send ter Alab tasks ae 

Hhenaderecemecre— RECP: 

send(msg. &head) ; 


he wdeereceice 5. =v: 


send(msg. &head); 
} 
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=ifdef Timer as 
else if ({(head. type =-—ININ Ree) 
&& (head.type <= MAX RP MSGTYPE) ) 
{ 
head.receiver = RECP;: 
send(msg.&head): 


else if ((head.type >= MIN CC MSGTYPE) 
&& (head.type <= MAX CC MSGTYPE) } 

{ . 
head. receiver = 9CG- 
send(msg,&head) ; 


else if ((head.type >= MIN DM MSGTYPE) 
&& (head.type <= MAX DM MSGTYPE) ) 


head.receiver = DM: 
send(msg,&head): 


} 

else if (head.type == GeTimes ) 
head. recéiwer = RECP: 
send(msg,&head) ; 7 
head.receiver = CC; 
send(msg,&head) : 
head.receiver = DM; 
send(msg,&head) ; 

4 /* end if ( GeTimes ) */ 
#tendif 
else 
/* ( t= FINISHED && ‘= GETIMES ) */ 


send(msg. &head): 
\ /* end while */ 
zifdef EnExFlag 
printt ("Exit GG ]PG@re a. 
#endif 


Sociale 


) )/ Se midieaael rig 
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/> 


get 


Pompine to get the next message from the network 


Messace (mptr.hptr ) 


eimai r imp tr: 
moruet mse hdr *hptr ; 


{ 


1 met 


S U aude. 
msglen, 
iain 


jee 


Saert 10sb/4| ; 
char rcvbuf[|[MSGLEN + 1]. 


sho 
ea) f 


- eT) 


iooueezs = ON, 
Gaps tr | 5 || ; 


rt msg rec: 


def EnExFlag 
printf("Enter get message\n") ; 


dif 


/* Check mailbox for message notices */ 
read mbx(mbxbuf): 


/* Read the message */ 
Pomcmmettrevbuf. mbxbut } 


/* Get the header information */ 


/* get sender */ 

hormiej—O: j <3: j+4) 
tmpstr[{[j] = revbuf [k++]: 

tmpstr|s;| = ~\0'-: 

Pptr--sender = str to num(tmpstr)-: 


/* get receiver */ 
for (j=0; j < 3; j++) 
tmpstr[j] = revbuf{k+4] ; 
Gmueteiy | = °\0; 
Dee Teceiver = str to num{tmpstr }) ; 
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j" ‘et the tsa 
oe 

tmpstr|j 
tmpstr{j] = 
hptr->type = str _ to num(tmpstr) ; 


e 
3: jtt+) 

= revbuf|k++].: 
O oe 

ic 


#iidel, pris 
m prnt(reweut ~ hpiae 


senma? f 
/* copy the message */ 
cr | 
while ( (k < MSGLEN) && (revbuf[k] != EOMsg) ) 
mptr[{[jt+}) = revbuf [k++]: 
mptr[{[j] = revbuf[k]; /* get EOMsg */ 


if (k >= MSGLEN) 
printf("***** Va ]wemo is MSChn twa 
printi("showld@bemincreased = Smog 


’ 


#ifdef EnExFlag 
printfi("Exit get @mesisace mae 


#endif 


} /* end get message */ 
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f/- Routine to check the mailbox for message notices 7; 


mead mbx(bu f } 


Gemar “but: 

{ 

eaort mS¢g rec: 
Short stat: . 
puloGt 105b|4| : 


#ifdef EnExFlag 
Pee (Ente read mbx\n") : 
-endif 


ise rec = FAUSE: 
Pamelewia! msg rec ) 


#ifdef pr flag 
printf("Calling qio, read mailbox\n"): 
zendif 
stat= sys$qiow(0, mbx chan, IO$ READVBLK. iosb, 
0,0, buf. MSGLEN, 0,0,0,0); 
eredct spr flag : 
Premier | Returmed from qio “nl ) ; 
ema i t 
if ((stat ‘= SS$ NORMAL) || (iosb[0|] != SS$ NORMAL) ) 
{ 
printf("** Mailbox read error, stat= %d (%x), ": 
Prenat os bO |= %d (7x yo" nn", stat. stat. 
ies) a | Peieors ol) |e 
ome geacetu | lea); 


} 


switch (buf [0] ) 


case MSGS INTMSG: 


{ 

Tne iC Gat — ate) Er: 
break; 

j 
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case a GeO Gas 
{ 


i 
connect({buf}: 


break: 
} 


case MSG$ CONFIRM: break: 


default: { 
printf ("*~* “Netwowwweuw10 rome, 
printf ("mbxbuf |0|= Ad (xx), ae 
buf [0], bution 
exit 2Tace timmermaiE 


| /*. engine hs 79) 
ee). “end! Whwikemmae, 


~irder aEnisx have 
Prime? (eee aces epee ee 


#endif 


J ENO Sere! soalae 
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/* Routine to read a message from a backend ~*/ 
read net (revbuf. mbxbuf)} 
char ue put. “mbxbuf ; 


{ 


com: unit. 


BEnum, 
feunie 
Seta. t-. 
ers | 4! ||: 


#ifdef EnExFlag 
printi("Enter read net\n") ; 
end if 
unit= mbxbuf; 


for (BEnum = 0: be dev[BEnum] != unit[1]; BEnum++) 


Pemesumum >= (next chan - 1}. ) 


{ 


Pmt Cannot locate unit number to ") ; 
Penti( read net with. Te aaale: 

printf("*** Searched through %d backends," ) 
Ppumeor( | next chan—= “7d **"\n", BEnum, next chan) ; 


exit gracefully(); 


} 
j 


aed e Wepie t | ae 
printf("Calling qio read from backend %d\n", BEnum) ; 
#tendif 


inc TOS READVBLK; 
stat= sys$qiow(0, be chan[{BEnum], func. iosb. 0,0, 
TowomevisGubN., 0,0. 0,0); 


Zitedef pr flag 


Orintt ("Returned from qio\n" ) ; 
endif 
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if ((stat '= $$$ NORMAL) jj (iosb[0] != SS$ NORMAL)) 
{ 


printf("** Read error be chan “%d. stat= Z2d(%x jn). 
printf("iosb|/0|= %d(@xje** n” . Bitumen stat 
| stat »o105b/0) 4 fost 0m 
ex tg racemase) 


} 


#itdeft Mmiix tales 
printil Expt "read ened) ere 
tendif 


} /* end read net */ 
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Po Imitialize Decnet to receive Gonnection requests 


net init() 

{ 

gh Srimdate, 1 
short iosb{4]: 


+#define NFB$C DECLNAME 0x15 
char nfb{[5] = { NFB$C DECLNAME, 0,0.0,0 }; 


struct sd { 
enc len : 
Saar pte 


} 


Opiate. 1 5, "GPCLB”™ ~}. 
Mem e—n 5, nib }; 
char tmpstr oe 


piidet EnkxFlag 
Dome Enter net init \n™) ; 
zendif 


f* create a mailbox */ 
stat=sys$crembx(0, &mbx chan, MSGLEN. MSGMAX, 0. 0. 


“] 


&netmbx) ; 
if (stat != SS$ NORMAL) 
{ 
Pawaiee DPrror creating mailbox, ”"); 
moe sStat— Yd (7x) **\n", stat, stat); 


exit gracefully(): 


} 


Pass ien channel to the net */ 
stat= syssassign(&netnam, &net chan. 0, &netmbx) ; 


Poet stat) !— 553 NORMAL) 
{ 
Pane, Mrronm in assign for netchan, "); 


Pom (  Sstat—d (7x) *~*\n", stat. stat); 
ccgut eracefully(); 


} 
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/* declare a network name ‘*/ 
stat= sys$qiow(0. net chan. IO$ ACPCONTROL. iosb, 


0,0. dnfb d. Sobymanc Ce Omnia 
if ((stat '= SS$ NORMAL) || (i0sb/@)=!— sss N@niaan 


printf("** Error declaring network Mame gm 
© 1) 1 pe) Gener cae lane aye 


} 


ry ede | aneeniens 
primtt( Bxit net init a Je 

#endif 

} 
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fe Outline 10 accept a network eonnection request / 
connect(buf ) 
iter but: 
short 
offset. 
Seta t. 
iosb|[4|; 
char nodespec|128|; 


meet sd 4 


i ht peer: 

ea. sp-br 

} 

nceb = { 0. nodespec }; 
long Goan vated |; 
short dvimmit en | 1 | ; 


feeestructure to 

struct { 
short 
short 
long 
short 
om & 


} 


avi = 


#ifdef EnExFlag 


get unit numbers for channels to the net */ 


len; / 
code. / 
Plies Ga / 
*unitlen: / 


cee ,3 


buffer length */ 

item code ce) 

Tic OmEe tment vo. / 
lemigeuh of @unit */ 

end ofedescriptor — / 


{ 4. DVI$ UNIT, dviunit, dviunit len, 0 }: 


pati ("Enter connect \n"); 


menad i f 


/* see if there are any channels available */ 


if (next chan > MAXBE) 


{ 


Pein ( 


WK Ox 


printf("attempted. next chan= %d 


exit grace 


; 


Too many connection requests "): 


fellas) 


ee tee Te Kt ead 


/* Extract network connect block from mar loon momen @ 


offset = buf[4] + 5: /* point towmeb ema aie oy 

neb.len = buf{offset]; /* put length intesou ree oy 

offset++: /* point past mcb lenesen 7 

for (i=0; i < neb.len; i++) /* get the ncb 7 
nodespec/[i] = buf [i + offset]: 


nodespec{i]= °\0’: 


#11 def pees albane 


printf("** nodespec= %s *~"\n 2 modemmec, 
printf({"** next chan—= “d= "9 \n” emercmcma dn): 
ema 
/* Assign the next channel to the net */ 
stat= sys$assign(&netnam. &be chan[next chan], 0, 
&ne tmbx ) ; 
if (stat != $5$ NORMAL) 
{ 
printf("*”~ Assign error )beuc nan cane ve 


printf("stat= %d (%x) **\n" ment seems t a0 creme 
exit gracefully ({), 


3 


/* accept the “commecuminan 
stat= sys$qiow(0. be chan[next chan]. I0$ ACCESS. 
7 iosb. OmO.0, dmcb.. 0,0 ,0 00m 
if ((stat != $S$ NORMAL) || (iosb[0] != SS$ NORMAL) ) 
{ 
printf("** Accept error be chan %d, stat— “dix oe 
Printee iosb(Oy= %d (Carey erate near rcnnn 
stat. iosb{0], iosb/O\gm 
Gxt t er acesmmoeley gin, 


} 
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) weeeeeunit numbers for the channels ~*/ 
eee swstgetdvi(l. be chan/next chan]. 
 0.&dvi. iosb. 0.0.0): 
if (stat != SS$ NORMAL) 
{ 
wince  skrroregettine channe!] mumber for BE "); 
printf("%d, stat= %d (%x) **\n", 
next chan, stat, Sit aly): 


eumumeracetul ly () ; 


ses omaitfr( 1); 
if (iosb[O] != SS$ NORMAL) 


mat Meer ror fettinggschannelanumber for BE ')- 
Poet od. 10sb|0|= Ada) ~*\n" next chan, 
| iosb[0], iosb[0]); 


Pouueerace: ul |y(); 
be dev[next chan] = *dviunit; 


/* increment the available channel pointer */ 
next wehana—-: 


#ifdef EnExFlag 

Memorex t connect \n" ); 
endif 
fee end connect */ 
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ne Routine to disconect all of themetwork fim = 


disconnect()} 


{ 


Pct Strate eee 


#ifdef EnExFlag 
printf("Enter Dis conmmect iui 
#tendif 


fo (= 18 ie cle taco, eos 


{ 
#1¢de 1 Mpa 
printf("Disconnect ing™ packende od 1. ne 


#tendif 
stat= sys$dassgn(be chan{[i]): 
if (stat '= $$$ NORMAL) 
printf("** Dassign Error for backend %d. "); 


printf(™stats=eyd (%x ye" *)\ nS Sie meecranceere ere ee 
} 
#ifdef EnExFlag 
ptimt f (7 xe cic neigh sill 
#endif 
} 


/* SET HEADER assigns values to the msg header ee 
Se pie archaea) 


head sender — Gal GveE. 


/* set the receiver */ 


head.receiver = &)M- /* the defamit 
} /* end set header */ 
/** Close all network connections before aborting aa 


exit. grace fame 


{ 
sleep(DELAY) : 
@ i 5 Comme cima): 
exit(); 
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fete) - Le NIB Ds BACKEND PUT-NET SOURCE CODE 


pees 
ee 
‘ 
eae 


include 
zinclude 
#include 
include 
#include 
+#include 
#include 
zinclude 


define 
char 
char 
enar 
short 


shor t 
short 


Simon t 
short 


Satur uc t Ss 


Sirive ¢ 


EES ES | 


* 


mbx chan: channel to mailbox 
be chan{MAXBE + 1]; /* chan’s to backends 
i Soackend.0 "is controller * 


NoBackends: /* the num of backends * 
next chan = 0; /*Stivemnext «caval chan * 


VAX/VMS P PCLB | 
k 

Manone yt te cr ee es eK ee | 
Sao oe ear denh) Oecdet ain: t 1 on 9 
<ssdef.h> [smvNISMEDeT Urn Status: codes —1/ 
—Vvodet. he / SVMSe/Osre turnecode's / 

<msgdef.h> /* DECNET msg definitions 
"commdata.def" /* MBDS common defs / 
Lmisieiden * MBDS msg-type defs ik 
isla cde f " /* MBDS compile flags / 
"beno.dcl" /* backend num declares */ 
MAXBE 16 /* max num of backends */ 
netbuf [MSGLEN] ; /* network buffer oy 
mbxbuf {MSGLEN] ; femal [box Dinter 7 
ms g |MSGLEN] : /* MBDS-msg buffer a) 
net chan: /* channel to DECNET */ 
- * */ 
/ 
/ 
/ 
/ 


d { 
it len; 
imac. ptr: 
leo  Stringe@escriptonrs tor; * / 


/* the network device name oF) 
netnam = { 5, " NET:"  }, 
/* the mailbox name ao 


netmbx = { 8, "P NETMBX" }; 


msg hdr head; 
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ma 1 ne 


{ 


etn ie 

agen Stopsys; /* Weep Tike ay 
mt Seeks 

char NoBEs |NoBElength +41]; 
Chiat BE Number|NoBElength +1] ; 


#ifdef EnExFlag 
Prin tt (ba terep oc lo eae 
#tendif 


/* Initialize intra-computer communication */ 


intisr sb Pers. 


/* set up to use DECNET */ 
controler me Uae 


/* receive a message from the controller */ 


receive(&msg[0], &head) ; 


/* The first message should be of type SetBEno. */ 
if ( head.type != SetBEno ) 

{ 

printf( "Error im PPCL.. 1s t imemieercmateate 

printf("be of type SetBEno" ); 

printi( " Type =Sedin’. heademape a) 

m prnt(dmsg[0]. &head): 

exit gracefully(); 


} 


/* get number of backends */ 


for( k=0,j=0 ; ( NoBEs[j] = msg[k]) != ’\0°’: 
eee 

NoBackends = str _to num( NoBEs ): 

lea 


/* get backend number */ 
for( j=0 ; ( BE Number{j| = msg[k|) != ’\0’: 
k++, j++ ); 


BACKEND NO = str_to num( BE Number ) ; 
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pace ndmare tain: ti NoBackends. BACKEND NO): 


fa eemiaii portion of program *¥/ 
Te psoys — FALSE: 
while ({ !StopSys ) 


/*recv amsg from a BE process */ 
receive(dmsg/|0]. &head) ; 

if ( head.type = Stop ) 

{ 

StopSys = TRUE: 

/* send the msg over the network */ 
j/*> backend 0 is the controller oy), 
put message (dmsg[0], &head. 0); 


} 


else if ( head.type — DesclIds ) 
{ /* send DescIds to other backends */ 
head.receiver = DM; 
Pom — 1: i <= NoBackends: i=i+l1} 


/* send the DescIds to other backends */ 
if ( i != BACKEND NO ) 
{ 


put message (&msg[0], &head,. i): 


} 
iw oweend for.” / 
[ee emdeelse wie*/ 


else 


Pp wesemd all other messages: to, controller */ 
/* backend 0 is the controller Pe 
put message({msg, &head, 0); 

ee enidimell s e 7) 


}/* end while */ 
¢ueeaef HEnExk lag 
poeetot | Exit p pel wbyn” ) ; 
zendif 


foes eemad-main */ 
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Tr Olt ieee 


I: 


send a message over 


put message(mptr.hptr.BEnum) 


Char “TAD: ae 

struct ms? hap ap 

Pnet BEnum: 

i. 

lenen Sivact. 
msglen, 
Panes. 
ks 

short iosb[4]:; 

char sndbuf [MSGLEN + 1], 
in Oath baer 0 


timp st © oe 


zifdef EnExFlag 


/* null message 


the network 


printf("Enter put message\n"): 


em Geluk 


hptr => sender Peer. 
hptr => receiver >= GeReirE 


k=0: 
/* copy header into message to be sent */ 
len num oto ost tr (hipt 1 send eT een 
for (j=0: j < 3; jt4) 

sndbuf [k++] = tmpstr|j]-: 
len num Co Ustr (tpt = wecenaams 3 tmpemer ) 
for (j=@s3).< 22a 

sndbuf [k++] = tmpstr|j]-: 
len num to str(hptitr->ty pews einpesamy 
for (j=0O: j < 3; j+4) 

sndbuf{k++] = tmpstr[j]; 
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[a copy the message ; 

j=0: 

while ( (k < MSGLEN) «&& 
((sndbuf [k++] = mptr[{[jt+]) != EOMsg) ): 


if (k >= MSGLEN) 
pits Moet” ~ Vea lue@of MSGLEN "): 
pasintf({"should be increased *****\n"); 


msglen = k: 
/* send the message */ 


Beede!l pr ‘flag 
Dmittwevcallingeqno write to backend %d\n", 
BEn um) ; 
m pase sndbuf, hptr) ; 
sendif 
func = [O03 WRITEVBLK; 
stat= sys$qiow(0. be chan{BEnum]. func. iosb, 0,0, 
- smabut. ms¢len. 0,0,0,0): 
merdetf pr f | ag 
printf("Returned from qio, write\n"); 
tendif 


if ((stat != SS$ NORMAL)||(iosb[0] != SS$ NORMAL) ) 
{ 
printf("** Write error be chan %d, stat= %d "); 
Presi | ox). 1osbi0i|= %d (7x) **\n", BEnum, 
ene OSD Ol) 105) 0 | } ; 
commmeeacetul ly()-; 


j 


/* let receiver know msg is there */ 
trodet pr flag 
ma Callime drow imterrupt\n" ) : 
endif 
fune = I1O$ WRITEVBLK IO$M INTERRUPT ; 
stat= sys$qiow(0. be chan[BEnum], func, iosb, 0.0. 
- peebure 1. .00,0.,0)\— 
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fa Ge ft pre. ae 
printf("Returned from eqio.  eneees ripe 


e¢endif 


if ((stat != SS$ NORMAL)]||(iosb[{0] != SS$ NORMAL) ) 
{ 


printf("** Interrupt error be chan “7d. stat— Ya") ; 


printf(" (%x), iosb|O\= %d(%x) = “in bene 
stat, Stat. 4 Ocbmede) =. 10s bi) Ole 
exit sm@acet ul ly [); 


} 


#ifdef EnExFlag 
pr ht f (Beer ee Ut etile so agen ie 
#endif 


} 
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J» 
i, 


Routine 


Omit) 2ieiZeeWeecmel | torerece ive connect 1ons 


Gomemollergnmet init() 


{ 


eiiet seteaiee 1 
short iosb|4]; 


+#define 


char 


pearie | sd 


char 


NFBS$C DECLNAME 0x15 


nfb{[5] = { NFB$C DECLNAME, 0,0,0,0 }; 


{ 


Pit Jeena, 
Giles ae pater 


} 


Cbymame— 4 o."PPCEB” }., 
nfb d = { 5. nfb \ 
tmpstr fone 


=mmdef Knexk lag 
Peotiiimter comtroliler net init\n") ; 


~end 1 f 


/* create a mailbox */ 


stat=sys$crembx(0. 


0, 0. &netmbx): 
if (stat != SS$ NORMAL) 
{ 
poem  hrror creating mailbox, "); 


&mbx chan. MSGLEN, MSGMAX. 


Pommmieestat— Ad (yx) **\n" stat, stat): 


Cx 


} 


Gemceiul ly (); 


Pp eassvemechanne] to the net */ 


stat= syssassign(&netnam, &net chan. 0, &netmbx): 
if (stat != SS$ NORMAL) 
{ 
eee  Krror invassien for netchan. "): 
pememin stat—eod (%x) “"An", stat. stat); 
eam raceiul ly { ) ; 


} 
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a 
/ 


/* declare a network name */ 
stat= sys$éqiow(0. net chan. IO$ ACPCONTROL. 
iosb. 0.0. énfb d. Gopuimamm0 ee 0mene 
if ((stat != SS$ NORMAL)]||(iosb[0] != SS$ NORMAL) ) 
{ 
printf("** Brror declaring Network namee= sense 
exe Taree eel aval ele 


} 


/* check mailbox for connection requests */ 
read mbx(mbxbuf): 


[* Aeqept the ceonuce tiongs 7s, 
connect (mbxbuf ) ; 


#ifdef EnkxFlag 


printf ("Exit econt1 ol ley Sei ie eee 


zendif 


} 
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meee ine to initialize Decnet links to backends 


Paenena met init{NoBEs. BEnum) 


int NoBEs ; 


{ 


int State, 1 
Siem t ios b | dale: 
Wuamenodespec(!28|, tmpstr|{ 5] ; 


were t sd 4 . 
etl Pe 1 
Chav Gee pita 
} 
CRE me — yo eee IN Pe 
ncb = { @. addlespeo 


#tifdef EnkxFlag 
Duleieeekaner backend wet Imnit\n’ ); 
#endif 


for(i=l; i <= NoBEs; i++) 
{ 
if (i != BEnum ) 
{ 


a asoien a chanmel to the met / 


stat= sys$assign(&netnam. &be chan|[ij, 0, 


if (stat != $$$ NORMAL) 
{ 


pout (""* Krror in assign be chan “%d, 


pt |  Stat— 7ode(vex)o yn”. 91. stat, 
ue race wl ly (qe 
j 
} /* end if i != BEnum */ 
} ee mecca) \ foray), 
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a 


Sunaeoae. 


/* Establish orgie ssl 


our 


( 
t 


i=l: 1 <= NoBEs: i++) 
f (i != 7B 


/* build metwork Conniectebmochk ms: 
strcpy(nodespec, "CSMV") ; 

HALT CO er trea reg CRE Lporr Siete 

Streat (modespec, tmpomtire 

streat (nodespec, ": ;\"0=GROEB aga 


ff 1 Tce: So saeereen 
printil backends cdmmode sipcicemm ae: 
print? (os ne Sete lode nme can: 


#endif 


} 


neb.len= strlen(nodespec): 
/* Request the connection * 
stat= sys$qiow(0. be chan{i], I0$ ACCESS. 
iosb, 0.070, €ncbh. 00) G2 
if ((stat != $S$ NORMAL)||(iosb{0] != SS$ NORMAL)) 
{ 
printf("* Access error be chan %d, "); 
printf("stat= d(x), 108b] 0) eax | nee 
i, stat, stat, 1osb|0]| , toapaieE 
exit gracefully(): 
} 
\  f/* end if °i != BEniaeee 
[vend sor i 3a 


#ifdef EnExFlag 


#¢endif 


} 


printt ("Exit backend me (aime sie 


96 





/* Routine to check 


read mbx (buf) 


cir *but : 

Sluo@rt connect rec; 
Short stat; 

ment lost| 4 | ; 


#ifdef EnkxFlag 


the mailbox for message notices 


ay 


Deoercit Enver read mbx\n") - 


emma 1 f 


eS 


connect rec = 


Dimelemll connect rec | 
mrdet pr flag 
printf("Calling qio, read 
ema ) t 
stat= sys$qiow(0, mbx chan, 
josb, 0,0, 


#ifdef pr flag 
preimtt( Returned from qio 

#endif 
Dt pides tat 


{ 


Dm) °° Mailbox read error, 


printf(" iosb[O|= %d (%x) 


coumerracefully() ; 


} 
Swill 


(buf [0] ) 


case MSG$ _CONNECT : 
{ 


GOnNnnNect rec = 


break: 
} 
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'= SS$ NORMAL)|| (iosb[0] 


mailbox\n"); 


10$ READVBLK., 
buf, MSGLEN, 0.0.0.0); 


sre 


'= SS$ NORMAL) ) 


Siete = oa (ux) , 
oom we stat. Stat. 
tos b 0) 1os b)| Oil}; 
TRUE ; 


Case MSG$ CONFIRM: 
case MSG$_ INTMSG ere 


de Panelsiee { 
printf("** Network erro; 
print? (“mbxbut }0)|)=—%d) (Ax) 
but |0) 2) buts 
ésote perace failileya im 


4 


/* end switche: / 
} /* end while */ 


#ifdef EnExFlag 
eat lasek lyse Via" = 
#endif 


{ | > send) vera mises, 
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Peerpomutime to accept a network 


connect (buf ) 


mar “buf; 
{ 
short ie 
on fs ete 
Stat. 
iosb{ 4]; 
char nodespec[128] ; 


Stenuet sae, 
iene len: 
elicir oater 


} 


ncb = { 0. 


pitdef EnExFlag 


nodespec 


putt Bunter connect\n") ; 


mema i f 


/* Extract network connect block from mailbox buf 


offset = buf[4] + 5: 

neb.len = buf|[offset | ; 

offset++; 

fom i —Ore i < ncb.len; 
nodespec|i|] = buf 

nodespec{ij= ’\0’; 


ifdef pr flag 
Dent: ("* * 


tendif 


point 
thie 


i * 


* 


i++) 
[i + offset]: 


nodespec= %s 
ent | next chan= Ad 7" \n". 


99 


put 


* OK 


He 


poe 


\n" 


len 


connection request 


POenG rb alee mc. t 1 
iio u Te mc Dp 
point past ncb length 
get the ncb 


nodespec); 


next chan); 


* 


— — 


/* Assign controller channe! 10 theme @/ 


Stat= sys$assign(&netnam. &be chan[O]. 0. &netmbx): 
if (stat != $S$ NORMAL) 

{ 

printf("**" Assign errom be chime ade )- 


printf("stat= %d (7x) ie eeemter cians 
Stat, S tance 
ex 1 tf Neer ac epee ae | 


} 


/* accept rt temconmec (ro ney 
stat= sys$qiow(0, be chan[0], 10% ACCESS. 
~~ fFosb, 0.0.0, eben o. 0 OnE 
if ((stat != SS$ NORMAL)||(iosb[0] != SS%$ NORMAL) ) 
{ 
DP taiemateta Accept error be chan %d, "); 
printf("stat= @d(%x). iosb)O)—s ca (ogi ee 
next chan, stat, stat. ioc) O) toc one 
exit gracefully(); 


} 


te ox * 


«ifdef EnExFlag 


printf ( Hecit ee ommrec tale 


6 Ti aoler 


} 


/* seildinconm ec fomey 
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ee Ooutvites 10 die@ennect alM@merwork@ links */ 


@isconnect () 


{ 


nt. State .: 


ie cled Meme! lave 
Peano seater Discemnect\n” ) ; 
se ta 1. 


for (i=l: i <= NoBackends; i++) 


fade l pr ef lag 
pe inti( Biscommecting backend %d\n", i); 


tendif 
stat= sys$dassgn(be chan|i]):; 
if {stat != SS$ NORMAL) 
Pot ee eDensataneinroan for backend %d. ") - 


Pent ome ee cl xe me we Stata stat); 


j 
#ifdef EnExFlag 
DGlwmit | wtiewmt Digsic onimect \n" } ; 
#endif 


} 


/* Routine to close network connections then abort */ 
exit gracefully() 


sleep(DELAY) ; 


disconnect(): 
engnt () 4: 
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